Method and Apparatus For Enabling Machine To Machine Communication

ABSTRACT

A method and apparatus for performing secure Machine-to-Machine (M2M) provisioning and communication is disclosed. In particular a temporary private identifier, or provisional connectivity identification (PCID), for uniquely identifying machine-to-machine equipment (M2ME) is also disclosed. Additionally, methods and apparatus for use in validating, authenticating and provisioning a M2ME is also disclosed. The validation procedures disclosed include an autonomous, semi-autonomous, and remote validation are disclosed. The provisioning procedures include methods for re-provisioning the M2ME. Procedures for updating software, and detecting tampering with the M2ME are also disclosed.

FIELD OF INVENTION

The present invention is related to wireless communication.

BACKGROUND

Machine-to-Machine (M2M) Communication is a form of data communicationbetween entities that, when deployed, do not necessarily require directhuman interaction. One challenge of M2M Communication is establishing aprotocol so that that deployed equipment may be managed remotely withoutany direct human interaction.

Existing M2M methodologies lack over-the-air protection of preliminarilyconfiguration identifiers; they have do not utilize information on theTrusted State (TS) of the M2M-enabled equipment in authentication,registration, and provisioning of the equipment; they do not ensure asecure change of subscribed operators for M2M-enabled equipment; they donot ensure that the Authentication and Key Agreement credentials used inpreliminary authentication of the M2M-enabled equipment is trusted; theydo not provide for secure updating of software and firmware, or forreconfiguration of M2M-enabled equipment; and they do not detect andreact to tampering with M2M-enabled equipment. Furthermore, the role ofthe M2M-enabled equipment user/subscriber lacks definition. Therefore,it would be advantageous to provide a method and apparatus for improvingM2M performance, security and reliability.

SUMMARY

A method and apparatus for performing secure Machine-to-Machine (M2M)provisioning and communication is disclosed. In particular a temporaryprivate identifier, or provisional connectivity identification (PCID),for uniquely identifying machine-to-machine equipment (M2ME) is alsodisclosed. Additionally, methods and apparatus for use in validating,authenticating and provisioning a M2ME is also disclosed. The validationprocedures disclosed include an autonomous, semi-autonomous, and remotevalidation are disclosed. The provisioning procedures include methodsfor re-provisioning the M2ME. Procedures for updating software, anddetecting tampering with the M2ME are also disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1 shows an exemplary block diagram of a communication system forMachine-to-Machine (M2M) provisioning and communication;

FIG. 2 shows an exemplary block diagram of a Machine-to-Machineequipment (M2ME);

FIG. 3 shows an example flow diagram of a procedure for autonomousvalidation;

FIG. 4 shows an example flow diagram of a procedure for semi-autonomousvalidation;

FIG. 5 shows an example flow diagram of another procedure forsemi-autonomous validation;

FIG. 6 shows an example flow diagram of a procedure for remotevalidation;

FIG. 7 shows an example procedure for provisioning or re-provisioning ofan M2ME.

FIG. 8 shows an alternative example procedure for provisioning orre-provisioning of an M2ME;

FIG. 9 shows an example flow diagram of a procedure for reprovisioningan M2ME for use with a new selected home operator.

DETAILED DESCRIPTION

When referred to hereafter, the terminology “wireless transmit/receiveunit (WTRU)” includes but is not limited to a user equipment (UE), amobile station, a fixed or mobile subscriber unit, a pager, a cellulartelephone, a personal digital assistant (PDA), a computer, a M2Mequipment (M2ME), a Home NodeB or any other type of device capable ofoperating in a wireless environment. When referred to hereafter, theterminology “base station” includes but is not limited to a Node-B, asite controller, an access point (AP), or any other type of interfacingdevice capable of operating in a wireless environment.

FIG. 1 is an exemplary block diagram of a communication system 100 forMachine-to-Machine (M2M) provisioning and communication. Thecommunication system 100 includes a M2M-enabled equipment (M2ME) 110, avisited network operator (VNO) 115, a registration operator (RO) 130, aselected home operator (SHO) 140, a platform verification authority(PVA) 150. The system 100 may also include an equipmentmanufacturer/supplier (E/S) (not shown).

The VNO 115 is represented in FIG. 1 as a single network entity,however, all access networks that are accessed for the purpose ofinitial registration and provisioning of the USIM/ISIM applications areconsidered to be VNOs. If the M2ME 110 becomes registered for adifferent SHO, then the VNO 115 remains a VNO. If the M2ME 110 becomesregistered to the SHO 140 that is currently the VNO 115, then the VNO115 becomes the SHO.

The VNO 115 is responsible for providing temporary network access toM2ME 110 where access credentials and authentication may be required.This could be based on the temporary network access credentials such asa PCID or any other temporary private ID. Where it is consideredpermissible, the VNO 115 may provide open network access to the DRF 170,where no credentials or authentication are required for access to atleast the services of the RO 130. For example, this function applieswhen the VNO 115 will become the customer's SHO after the registrationand provisioning events. After registration and provisioning procedureshave been implemented, the VNO 115 will provide full network (and IMS)access using the provisioned USIM/ISIM applications.

The RO 130 as shown includes an ICF 160, a discovery and registrationfunction (DRF) 170, and a downloading and provisioning function (DPF)180. However, one of skill in the art would recognize that the ICF 160,DRF 170 and the DPF 180 could also be located in separate entities orcollapsed into one entity.

The ICF 160 is the function or authority responsible for the validationof credentials that allow temporary access to communication networks forthe purpose of registration and provisioning of operational networkaccess. The functions of an ICF 160 include issuing of temporarynetwork-access credentials and any temporary private identifier for eachM2ME 110. These can be used for authenticating initial temporary networkaccess to enable the USIM/ISIM application provisioning procedure totake place. The ICF 160 may also be configured to provision the M2ME 110with downloadable M2M keys, configurations, and applications over theair for provisioning and reprovisioning procedures discussed in detailbelow.

The ICF 160 may also be configured to provide the terminal supplier topre-configure the M2ME 110 with credentials, issued by the ICF 160. Inorder to provide these credentials, the ICF 160 must be configured toprovide secure transmission of the credentials to the organization thatis responsible for embedding them in the M2ME 110. The ICF 160 may alsobe configured to register the credentials in a database, and performvalidation of the credentials when requested by a relying party. Thiscould include the secure transmission of authentication vectors and/orother related data to the relying party. It should be noted, prior tosuccessful registration of the M2ME 110 to the SHO 140, all accessnetworks are considered as visited networks. This allows for transparentconnectivity to the SHO 140 through a conventional network without anynetwork changes.

The DRF 170 is the function that enables the after-purchase selection ofa specific SHO 140 and registration of the M2ME 110 with that SHO 140.It may be an independent service, alternatively it may be operated bythe SHO 140 whose RO 130 may be contactable only via the SHO's 3GPPnetwork or may be contactable directly via the Internet and discoverablee.g. using functionality in the M2ME 110.

The DRF 170 should support at least the following usage-relatedfunctions: (1) allow the customer to select the SHO 140 after deliveryof the M2ME 110 from a supplier; (2) allow the M2ME 110 to have an IPconnection to the RO 130 using either temporary authenticated networkaccess or limited open network access; (3) allow the M2ME 110 to requestfor a USIM/ISIM application provisioning to take place via a visitednetwork operator as the M2ME 110 is not yet associated with any SHO 140;(4) approve the provisioning request and to authorize the DPF 180 toprovision the M2ME 110; and (5) support registration of the M2ME 110 bythe owner of the M2ME 110.

In order to support the usage-related functions described above, the DRF170 may support association of the M2ME 110 with a SHO 140.Alternatively, the DRF 170 may be discoverable and addressable directlyusing the IP connectivity provided by the VNO's network. In either case,the DRF 170 must support validation, via the PVA 150, of the credentialswhich the M2ME 110 possesses as proof of the authenticity of its trustedenvironment (TRE) 230. The DRF 170 must also support a connection to theDPF 180 for authorization and audit. It should also be noted, validationcan be not only of the credentials but also the TRE 230 and optionallythe whole M2ME 110 if the TRE 230 so desires. For example, validationmay include establishing the trustworthiness of the M2ME functions.

The DRF 180 may also support generation or obtainment of a package ofdata to be downloaded to the M2ME 110 such as USIM/ISIM credentials,files and executables. The DRF 180 may also be configured to transmitthis data securely to the PS. Alternatively, these functions could beprovided by the DPF 180.

Finally the DRF 180 may also facilitate the setting up of a securityassociation between the M2ME 110 and the DPF 180. This may require thegeneration and transmission of security tokens over secure channels tothe M2ME 110 and DPF 180.

The DPF 180 enables the remote provisioning of USIM/ISIM credentials tothe M2ME 110. The functions of the DPF 180 include receivingauthorization from the DRF 170 to provision the M2ME 110. This couldinclude providing a security token for communicating with the M2ME 110.The DPF 180 is also responsible for receiving from the DRF 170 theapplication package to be downloaded. The DPF 180 may alternativelygenerate this from stored rules and advise the DRF 170 of thecredentials that have been downloaded to the M2ME 110.

The DPF 180 is also configured to support the provisioning of aUSIM/ISIM application or USIM/ISIM parameters to the M2ME 110 as isdescribed below. In addition to provisioning, the DPF 180 may also beconfigured to perform future updates to a USIM/ISIM application orUSIM/ISIM parameters to the M2ME 110 and future provisioning of newapplications. Included with these functions, the DPF 180 may also beconfigured to notify the DRF 170 of a successful or unsuccessfulprovisioning event.

The SHO 140 is the network operator which has the commercialrelationship with the customer, or end user of the M2ME 110 and isresponsible for billing the customer. The SHO 140 may operate some orall of the other roles, especially DRF 170 and DPF 180, or they may allbe separate commercial entities with an operational relationship withthe SHO 140 and with each other.

The M2ME 110 initially is not commissioned to operate with a serviceprovider and so in communication with the VNO 115 establishes a channelto the RO 130. In order to provision service, each M2ME 110 has its owntemporary private identity, such as a PCID, which enables any VNO 115 torecognize the M2ME 110 and permit temporary access to the services itoffers and to direct the initial connectivity messages to theappropriate network components, in order to download and provisionservice with an operator.

The PVA 150 is an authority responsible for credentials that attest tothe authenticity of the secure device within the M2ME 110 that is usedfor storage and execution of downloaded USIM/ISIM applications. Thisfunction could be performed by one or more commercial organizations whoissue credentials such as certificates and key pairs and who providecertificate validation services. The secure device could be a UICC, TRE,or some other form of secure module embedded in the M2ME 110. Thisfunction is required where strong authentication of the secure device isa pre-requisite for provisioning of the USIM/ISIM applications. The PVA150 may also provide functions such as creation and issuing ofcredentials to attest to the security of the secure device within theM2ME 110. However, it is also possible that this function could beperformed by another entity. The PVA 150 may also provide functions suchas validation of the credentials described above, when requested by arelying party using the requisite protocols. This could include thesecure transmission of authentication vectors and/or other related datato the relying party. The PVA 150 may also provide functions such asmaintenance of data relating to the validity of a device's issuedcredentials.

The equipment manufacture/supplier (E/S) (not shown) also plays a rolein the communication system 100 of FIG. 1. Specifically, the M2ME 110securely obtains credentials from the ICF 160 for authentication for thetemporary initial network access. The E/S may also supportre-configuration of the M2ME 110, prior to delivery to the customer,with those preliminary network-access credentials in order to allowtemporary initial network access. Further, the E/S may obtain securelyfrom a PVA 150 the credentials for use in proving to the DRF 170, viathe ICF 160, that the M2ME 110 complies with a standardized set ofsecurity requirements. This activity may be contracted out to anapproved organization with the required secure infrastructure.

The E/S may also be responsible for pre-configuration of the M2ME 110,prior to delivery to the customer, with the credentials. Thispre-configuration activity may be contracted out to an approvedorganization with the required secure infrastructure. The E/S may alsoprovide a means for the terminal owner to select the desired DRF 170 andSHO 140, or for this to happen automatically when the terminal isconnected to an access network (AN).

FIG. 2 shows an example diagram of the M2ME 110 of FIG. 1. The M2ME 110includes a transmitter 215, a receiver 220, a processor 225, a trustedenvironment (TRE) 230. Optionally the M2ME 110 may include a globalpositioning system (GPS) unit 235, a subscriber identity module (SIM)240, and a secure time unit.

The M2ME 110 may be configured to support many different trustmechanisms such as the TRE 230, or any other trusted processing orstorage mechanism such as a SIM 240 or ISIM. These trust mechanisms mayalso be more fully integrated into common AKA protocols to include the‘trust state’ information and/or any keys protected by the TRE 230 inthe M2ME 110, to protect any communication (not just transmission of thePCID) between the M2ME 110 and a network element before full AKA cantake place and after authentication has been established.

Optionally, the SIM 240 may also be enhanced to include the functions ofa trusted processing module (TPM) or mobile trusted module (MTM) tosupport the operations described above. Alternatively, the SIM 240 mayoperate closely with a TPM or MTM within the M2ME 110 to achieve thedesired function. It should also be noted that the functionality of theSIM may also be achieved within the TRE 230. This allows greaterflexibility in identity management.

Optionally, the M2ME 110 may be pre-provisioned with at least one AKAroot secret that is installed by the E/S, one of which is active at anygiven time. The AKA root secret(s) may be protected by the SIM 240, andshould never be changed. The SIM 240 may be configured to derive sessionkeys from the active AKA root secret.

The M2ME 110 may also be configured to provide trust state informationto the ICF 160. The trust state information may then be used forpreliminary authentication when the M2ME 110 attaches to the VNO 115.The trust state information may also be used to derive session keys (CKand IK).

It should be noted that the TRE 230 functionality may be implementedexclusively on one component, or distributed between an embedded trustedcomponent within the M2ME 110. Alternatively, the TRE 230 functionalitymay be implemented on a removable SIM module.

An example of a formula to bind the PCR register value to the sessionkey CKn and IKn, where n refers to the index for the most current updateof the CK_(n) and IK_(n) may be:

CK _(n) =f3_(K)(RAND∥PCR0_(n))

IK _(n) =f4_(K)(RAND∥PCR0_(n)).   Equation 1

where f3_(K)( ) and f4_(K)( ) refer to the AKA key derivation functionsfor the cipher key and integrity key, respectively, out of the sharedmaster secret K, RAND is the random nonce within the AuthenticationVector (AV) generated by the CATNA and sent to, and thus shared by, theM2ME 110 in the AKA process, and PCR0_(n) refers to the most currentvalue of the PCR0 register inside an MTME on the M2ME 110. Note that thecurrent value of PCR0 register signifies a description of the mostrecent post-boot trust status of the M2ME 110.

Note that according to Equation 1, the values of CK_(n) and IK_(n)change when and if the PCR0 values of the M2ME 110 changes between thetwo boots. In order for such a scheme to work, the ICF 160 must also beaware of the change of the PCR0 value (or more generally the ‘truststate’ of the M2ME 110 when there is a change in the post-boot truststate of the M2ME 110. This can be made possible if the ICF 160 is madeaware of the schedule and substance of any legitimate or authorizedupdate of the M2ME's OS, firmware or applications that affect thepost-boot trust state of the M2ME 110. This may be done by involving thePVA 150 and/or the ICF 160 in the procedures described below. One canthen ensure, following appropriate procedures, that the AKA cipheringand integrity keys shared between the M2ME 110 and the ICF 160 areupdated and be made useful for authentication of the M2ME 110 in a waywhere the session keys reflect the most current ‘trust state’ value ofthe M2ME 110, thereby enhancing freshness and security of the AKA keyderivation process.

It should be noted that other binding formulas than that of Equation 1may be considered, as long as the session keys can be updated in thesame way between the M2ME 110 and the ICF 160 and the update procedureitself at the M2ME 110 is performed in a trusted execution environmentsuch as those provided by the use of Trusted Computing technologies.

The TRE 230 is a logically separate area in the M2ME 110 with hardwaresupport for this separation. It is not necessarily a removable module,i.e. it can function within an IC or functions that are distributedacross a group of ICs. The TRE 230 defines logical and physicalinterfaces to the outside world, which are usable only under control ofan entity which is authorized to communicate directly with the TRE 230.

The TRE 230 provides a root of trust for the secure storage and secureexecution environment for multiple manageable identities (MIDs) and forcertain functions concerned with the provisioning and management ofMIDs. The MID is a generic term for a full secure application and itsassociates parameters, credentials etc. It could incorporate anysubscription management functionality such as a standard USIMapplication and keys, or other secure applications such as ISIM orsecure payment applications. Hereinafter, MID may be used to refer to amanageable identity, subscription management identity, USIM application,ISIM application, virtual SIM (vSIM), or any other dynamic secureidentity solution.

The TRE 230 may also be pre-provisioned in a secure, out-of-bandfacility with any required cryptographic keys and other credentials.Other security-critical functions of the TRE 230 are pre-provisionedonto the M2ME 110 in the same way. Further functionality may betypically provisioned by download after the M2ME 110 is issued.

The TRE 230 also provides a degree of protection against physical andlogical attacks, supports and enforces its own security policy, and issufficiently secure as to allow the storage and execution of MIDs thatare currently implemented only in UICCs or other smart card platforms.The TRE 230 also has interfaces to parts of the M2ME 110 that areoutside the TRE 230.

The TRE 230 has its own embedded, unique identity that is typicallyassociated with the identity of the M2ME 110 that, where used, is alsoembedded in the TRE 230. As such, the TRE 230 may be configured tosecurely authenticate those identities to the issuing authorities usingstandardized protocols. The issuing authorities can then validate theTRE's identity as being that of a valid, issued, TRE 230 and M2ME 110.Each of those identities is embedded as part of a physically secure,out-of-band process that takes place before the M2ME 110 is issued.

The TRE 230 may be implemented in an embedded UICC with certain enhancedfunctionality, or alternatively as an integrated solution on the M2ME110 utilizing hardware and software components provided by the M2ME 110.If the TRE 230 is implemented in an enhanced UICC, the TRE 230 wouldstill support downloading and remote provisioning and management of MIDsand the functionality of the manageable identity engine (MIDE) withinthe TRE 230.

If the TRE 230 is implemented as an integrated solution in the M2ME 110,the M2ME 110 supports integrity checks of the software code and datathat make up the TRE code base. TRE code should be checked at least onceat power up/boot-time of the M2ME 110. Optional code checks could beconducted during operational use of the M2ME 110 as a background processat defined intervals or at certain triggers/events. Additionally,coverage of the code checks may be extended to cover a full or partialcheck of the M2ME 110.

In an alternative enhancement, the TRE 230 may include support formultiple isolated, trusted domains, each owned by a stakeholder-owner,within the TRE 230. Such domains could be isolated from each other,against tampering and unauthorized access and provide inter-domainservices such as authentication and/or attestation functionality.

In some use cases, an M2ME 110 would operate in a dormant state for mostof its deployment cycle and would connect to the 3G networks onlysporadically or in frequently. In such a case, the run-time integritychecks of the TRE's software code may be made to take place during thedormant-state periods. In this manner, the code check would notinterfere with other processes within the TRE 230 or the M2ME 110, andthe result of a code check could be made to be ready when the M2ME 110re-connects to the SHO 140.

Each M2ME 110 must be assigned a temporary private identity that isunique to the M2ME 110, the provisional connectivity identification(PCID). The PCID is a temporary private identity that uniquelyidentifies each M2ME. This PCID, where required, needs to be installedin the M2ME 110 by the ES in order to allow the M2ME to register in a3GPP network before being associated with any specific SHO, such as SHO140. The PCID is initially issued by an ICF 160, which sends the PCID tothe ES with which it has a provisioning relationship. The ES thenprovisions the PCID into the TRE 230 of the M2ME 110. When a PCID ispresented from the M2ME 110 to a VNO 115, the VNO 115 may recognize itas a having the format of the standard IMSI and then subsequently directthe M2ME 110 to a RO 130 to establish initial connectivity forprovisioning.

In one embodiment, a single PCID may be valid for a limited time span(hereinafter a “validity period”) that is enforced by the M2ME 110. Thevalidity period may be controlled specifically by its TRE 230. Each M2MEdevice may receive a PCID and a validity period. After the time expires,the M2ME 110 may remove the PCID. The PCID can then be reused whenanother M2ME (not shown), which is provisioned with the same PCID,attempts to attach to the core network. The validity period of thesecond M2ME's PCID, however, should not, in general, overlap with thatof the former M2ME's PCID.

After the first M2ME 110 has no use for the PCID again, typically thePCID may not be re-issued to a new M2ME until the exhaustion of theappropriate validity period for the M2ME 110.

In another embodiment, PCIDs may be systematically reallocated (withoutconcurrent usage of PCIDs). This may cover the life-cycle of the M2ME110. A limited number of PCIDs may be systematically preprovisioned toan M2ME 110. This may allow an autonomous management of initial networkconnectivity while exploiting the capabilities of the TRE 230. It isassumed that M2MEs are released in groups of size N. The M2MEs of thejth batch are referred to as M_i,j where j=1, . . . , M. PCID assignmentmay be initialized with a matrix (P)_{i,j} of size N×M. M2ME 110 M_i,1gets column P_i,* loaded into the TRE 230 during manufacture. When theM2MEs are released, a secure timer or monotonic counter is initialized,activated and put under control of the TRE 230. The M2ME 110 of batch 1,i.e., M_i,1, uses P_i,1 for a determined time span T or a predeterminednumber of times based on the time or counter that was initialized. Afterthe given time (validity period), the TREs of M_i,1 discard P_i,1 anduse P_i,2. It should be noted that the time span or number of usagesshould be such that the second batch is not yet released. The secondbatch M_i,2, when released, also starts to use P_i,1, which at thispoint in time, is freed by M_i,1. Ideally, MxT covers the wholeoperation time of all M2MEs that need to be supported by the network.

This embodiment may allow the network to determine where a device is ina lifetime cycle. Previous PCIDs can be securely reassigned to newdevices. The scheme exploits the intrinsic trust relationship of M2MEmanufacturer with the TRE 230. Handling of the PCID column vector withinthe TRE 230 and enforcement of the time limits by the TRE 230 yieldsassurance toward the PLMN operator that concurrent use of PCIDs isprevented and the M2ME 110 has a valid PCID for use throughout itsoperation time.

However, this embodiment may impact the network operator, as the networkoperator may deliver the PCID sets to the manufacturer at a certainpoint in the manufacturing process, or install the PCID sets in a securefacility, before release. Also, the M2MEs may be preprovisioned withmultiple PCIDs. The M2MEs may support reprovisioning of the laterbatches of PCIDs. Multiple M2MEs that share the same batch of the PCIDsat any given time may have ‘chance’ collisions where two or more M2MEsmay choose the same PCID from the same batch and try to connect at thesame time, resulting in ‘PCID collisions’. The chances of PCIDcollisions may be smaller if the size of the batch (the size of the row,N) is made much larger than the number of M2MEs using the same batch ofPCIDs and if the M2MEs choose the PCID to use in a random manner.

The management of PCIDs with time limits requires a synchronization ofM2MEs' internal clocks within given precision limits. This must cover,for example, power-down events of a single M2ME 110, after which aresynchronization may become necessary. Therefore, the TRE 230 shouldhold and manage a time base and support synchronization with trustedtime sources in the network. Optionally, the TRE 230 may rely on atrusted time source located in the M2ME 110, as is shown in FIG. 2.

An M2ME 110 may be equipped with autonomous geo-positioning equipment,such as a GPS 235. The M2ME 110 TRE 230 has secure access to thegeo-positioning equipment.

The M2ME 110 can be distributed in different areas and arranged suchthat no two M2MEs may physically establish a radio connection to thesame access network (AN) cell or base station at the same time. MultipleM2MEs thus can be preprovisioned with the same PCID but also adestination geo-position (D), the latter being unique to each M2ME, anda tolerance range (r). This data may be stored securely inside the TRE230 or cryptographically secured so that only the TRE 230 is able toaccess the data.

Before an initial network access attempt by the M2ME 110, the TRE 230determines the current geo-position and checks if it coincides withposition D within the tolerance range r. If it does, the TRE 230releases the PCID for initial network access. In this manner the AN maybe assured that no two M2MEs will attempt access via the same cell usingthe same PCID.

Nonetheless, in some cases the AN may need to distinguish concurrentaccess attempts using the same PCID from different cells. Therefore itmay need to keep record of (PCID, cell ID) pairs within the initialnetwork connectivity service. Therefore, there can be some impact to thecore network in this case.

In an alternative embodiment, access to the network by an M2ME 110 ispermitted via predetermined network cells only. The predeterminednetwork cells are identified by their network cell identifiers which areloaded into the M2MEs' TREs. They replace the pair (D,r).

In yet another alternative embodiment, M2MEs may be movedgeographically. Network access is disabled when the M2ME 110 is moved.To enable M2ME mobility, the M2ME 110 can be preprovisioned with a setof triples (PCID, D, r) that designate the different places in whichcertain PCIDs may be used. Before initial network connection attempts ofthe M2ME 110, the TRE 230 checks if the current geo-position is withinone of the ranges r of one of the destinations D and releases thecorresponding PCID in the case of success.

Additionally, (PCID, D, r) triplets can be assigned a lifetime, i.e. atime span of allowed usage which is used and enforced as set forthabove. The credential will be in a quintuple (PCID, D, r, t1, t2) wheret1 and t2 designate the starting and ending times of the validityperiod. This describes a path for allowed movements of an M2ME 110. Forexample, the movements of an M2ME 110 can be controlled in a mobiledeployment scenario such as in a vehicle. When the M2ME's TRE 230 isforced to reconnect frequently or otherwise use the PCID, a failure maybe detected by a network service (in the form of a time-out) and beinterpreted as the M2ME 110 leaving the determined path, thus causing analarm.

The methods and apparatus set forth above may be insufficient toaccommodate for mobility and/or PCID management requirements for theM2ME 110 throughout their lifetime. Therefore, a method to manage, i.e.reprovision and delete, (PCID, D, r, t1, t2) quintuplets is desirable.

Such quintuplets may be reprovisioned using a PCID update service (PUS).A PUS may identify the TRE 230 (uniquely corresponding to the M2ME 110)that it updates. The PUS may be part of the CCIF service or a separatecomponent in the network. The update may include changes to one or more(PCID, D, r, t1, t2) quintuplets. The TRE 230 identity (ID) may be sentto a network service which can associate TRE IDs to a current network(IP) address. For example, a network entity may be a PVA 150 which hasvalidated the integrity of the TRE 230 and M2ME 110 in the course ofobtaining full network connectivity, or a Connectivity CredentialsIssuing Function (CCIF) that works with the PVA 150 to confirm thevalidity of the M2ME 110, issue new PCID(s) and remotely provision thenew PCID(s) to the M2ME 110. The remote provisioning may also bedelegated to a DPF 170 in the network.

The repositioning procedure begins when the PUS connects to the targetM2ME 110 and TRE 230 and requests a validation of its state, e.g. via aplatform validation procedure described below and shown in FIGS. 3-5.This may indicate to the PUS that the TRE 230 will safely discard theold (set of) (PCID, D, r, t1, t2) quintuplets and install the desirednew ones. Upon a validation success, the PUS may deliver a new (PCID, D,r, t1, t2) quintuplet and a list of old ones to be discarded. The TRE230 autonomously installs the new quintuplet and (to ensure continuedconnectivity) discards the old ones.

In another embodiment, a TRE 230 may be capable of producing (pseudo-)random numbers which can be adjoined with PCIDs to alleviate collisions.The AN may be enabled to keep track of and distinguish between theadditional information.

Communicating entities are the M2ME 110, TRE 230 and a network accesspoint (NAP) (not shown). The NAP may be, for example, an eNodeB (eNB)associated with the VNO 115. The TRE 230 generates a random number(RAND) to be used in a single initial network connection attempt. TheTRE 230 applies an integrity protection method, such as a keyed hashfunction where RAND enters a second parameter, for example, additionaldata as needed (D1), and a PCID. The TRE 230 sends this data as:TRE→eNB: RAND∥PCID∥D1∥M1:=MAC(PCID∥D1, RAND).

The eNB verifies the message authentication code (MAC) and builds areturn package out of payload data (D2) and the received data as:eNB→TRE: D2∥M2:=MAC(PCID∥D2, M1, and sends it to TRE.

This method extends to all subsequent messages exchanged in the initialnetwork connection. Subsequent message exchanges will include a MAC of adata element that includes any new message element and the immediatelyprevious exchange's MAC. The eNB and the TRE 230 can distinguishmessages during this communication using the last value M_(n-1) to buildthe new M_(n).

To avoid man-in-the-middle type attacks on this communication, apreestablished, or negotiated/shared secret may be included in themessages for authentication of the communicating parties.

The inclusion of the PCID proper in the MAC values is optional, but canbe advantageous to build a hash table and to efficiently distinguishconcurrent active network connection attempts of multiple M2MEs withdifferent and/or common PCIDs. This may prevent the sending of the PCID(possibly in clear text) in every message of the initial networkconnection communication, which can be a security issue.

The eNB may keep a table representing the state of all concurrentlyactive network access attempts (hereafter called channels) using PCIDs.For each channel, it contains the information in TABLE 1.

TABLE 1 PCID index Active hash value Data history I M₂ RAND, D₁, D₂

The first column contains an index of the PCID belonging to thisparticular channel, pointing to an entry in the list of all PCIDscurrently active for all channels PL:=[PCID1, . . . PCIDN]. This savesmemory on the above table, but if memory is not an issue, the column cancontain the full PCIDs.

The eNB receives the third message on a channel:

TRE→eNB: D3∥M3:=MAC(PCID∥D3, M2)

For i=1, . . . , N until success of the following procedure, the eNBselects PCID_(i) from PL. For all table rows with PCID index I in thefirst cell, the eNB calculates M:=MAC(PCID_(i)∥D₃, M₂), wherein M2 istaken from the second cell in the row. If M=M₃, success state is reachedand the search procedure ends. The row number of the channelcorresponding to the last received third message is returned. D₃ isadded to the data history and M₂ is replaced by M₃ in the active hashvalue cell of the selected table row. This process is iterated for allsubsequent communication steps.

Alternatively, instead of the PCID, messages after the first messagecould contain the index I of the channel to find the associated channelof a subsequent message even more efficiently.

In cases where resources, in particular memory, of the M2ME 110 and/orthe eNB are limited, active PCIDs may be locked. This may beadvantageous by preventing the M2ME 110 from using a locked PCID.

For example, a M2ME 110 has opened a channel with an eNB for a PCID. Asecond M2ME, (not shown) having a second TRE (not shown) attempts toopen a channel to the eNB using the same PCID, while the first channelis still open. The eNB may respond to the first message of the secondM2ME's TRE by transmitting M1. Thus the second TRE is notified that thisPCID is currently occupied. The second TRE may use another PCID from apool of installed PCIDs for another channel opening attempt, or may waita predetermined time span before using the same PCID again.

Alternatively, PCIDs may be actively deallocated by the involvedentities. The M2ME's TRE 230 may discard a used PCID when it has beenused for obtaining full network connectivity, (i.e. after download ofthe pertinent credentials). Various events may cause the discarding of aPCID. For example, discarding the PCID can be triggered if the TRE 230has reached a state in which full network connectivity is assured suchas by a successful run of a protocol for that purpose. Discarding thePCID can be triggered if a validity period has expired, if a networkentity such, as the eNB, security gateway, or a dedicated PCIDmanagement entity, forces the discard, or if an entity outside thenetwork, such as the manufacturer of the M2ME 110, forces the discard,which may establish a secure connection through the VNO 115 to the M2ME110.

Regardless of what event triggers the discard, information about theevent can be used to de-allocate it properly, that is, free it for reuseby other M2MEs. A connection may be established from the TRE 230 to themanufacturer of the M2ME to signal the deallocation event. Themanufacturer may update the running list of free PCIDs and can reusethem to impress PCIDs on new M2MEs upon release.

Alternatively, an entity in the network such as the ES, the existing SHO140, a new SHO not shown or the ICF 160 may be configured to update thePCID, in order to facilitate future connectivity operations upon forexample initiation of a change of subscription from one SHO to anotherSHO. Once the M2ME 110 has been provisioned, an updated value for theinitial network access credential, PCID could be delivered as a MID tothe M2ME 110 for future use in assisting with provisioning service witha new SHO. The credentials would be extracted, stored, and usedexclusively in the TRE 230 of the M2ME 110.

Before a credential re-provisioning process due to change of SHO, theM2ME 110 may be informed that its existing initial network accesscredential, PCID has either expired or is about to expire. The M2ME 110may request and receive a new initial network access credential from theE/S, existing SHO 140, new SHO or the ICF 160. Alternatively, the M2ME110 may receive a new PCID from one of these network components, sourcedfrom the E/S or from a new SHO, so that it could route the M2ME 110 tothe new SHO when the M2ME 110 makes a new initial network access attemptfrom a pristine state.

In one embodiment, the M2ME 110 may be pre-configured with the U(I)SIMapplication, a PCID, and more than one set of AKA root secrets, whichare to be used one active set at a time. Upon change of the PCID, theM2ME 110 is instructed to use the next set of AKA credentials so thatthese may be used to provide 3GPP connectivity to the M2ME 110, thusfacilitating a change of operator and subscription re-provisioning to anew SHO.

The above describes just a few of the possible methods for replacementof the initial network access credential and re-provisioning service. Itshould be noted, that consideration of security in all deallocationprocesses requires that a PCID is not to be transferred in clear text indeallocation processes. Further, for all deallocation processes,communication partners should be authenticated in deallocationprocesses.

There are three fundamentally different possibilities for performingvalidation or authentication of the trust state of the TRE 230, or theM2ME 110 and the associated data and credentials. The possibilitiesinclude: (1) autonomous validation; (2) semi-autonomous validation; and(3) remote validation. Each will be discussed in more detail below withreference to the architecture shown in FIG. 1.

Autonomous validation is a procedure whereby the internal validation ofthe M2ME 110 is assumed to have occurred before the M2ME 110 will allowitself to undergo network attachment.

A semi-autonomous validation is a procedure whereby the validity of theM2ME 110 is assessed within the M2ME 110 itself without depending onexternal network entities. The result of such validation and requiredevidence of the binding of authentication of the TRE 230 to the validityof the M2ME 110 is signaled to a remote entity such as the PVA 150,which makes a decision based on the content of the messages from theM2ME 110. The signaling from the M2ME 110 to the PVA 150 should beprotected.

A remote validation consists of procedures whereby an external networkentity (e.g. the PVA 150) directly assesses the validity/integrity ofthe M2ME 110 after it receives evidence for the validation generated bythe M2ME's TRE 230, as well as evidence of binding between the TRE 230and the M2ME 110. The communication taking place between the M2ME 110and the PVA 150 for remote validation should be protected.

If the TRE 230 performs autonomous validation of the integrity of theM2ME 110, no direct evidence of the validation is provided to theoutside world. The outside world assumes that, due to the way in whichM2MEs and TREs are specified and implemented, an M2ME 110 which failsits internal integrity checks will be prevented by its TRE 230 fromattaching itself to a network or from obtaining an authenticatedconnection to a remote entity. For example, the process of secure bootfacilitates a secure bring up of the code in a M2ME 110 but there is noexternal signaling that this is the case other than reliance on theequipment fulfilling this purpose.

FIG. 3 shows an example of autonomous validation procedure 300 performedby the TRE 230 to validate the integrity of the M2ME 110.

First, the TRE 230 checks if it has achieved a predefined state ofsecure start-up, at 310. Next, the TRE 230 checks if a pre-definedportion of the rest of the M2ME 110 that needs secure start-up hasachieved a predefined state of secure start-up, at 320.

Further checks may then take place either by the TRE 230 itself or by ameasuring component in the M2ME 110 external to the TRE 230 butintegrity-protected by the TRE 230, at 330. In such later-stage checks,integrity of other components, configurations, or parameters of the restof the M2ME 110 is checked when they are loaded or started, or at other,pre-defined run-time events, wherever such is available to the measuringcomponent.

Finally, the TRE 230 permits the M2ME 110 to engage in a requestedauthentication procedure, at 340.

Autonomous validation is the most economic method in terms of externalcommunications required. However, autonomous validation does not permitany outside entity to independently assess the integrity of the TRE 230or the M2ME 110 during network access or during a phase of uninterruptedconnectivity. That is, the trustworthiness of the M2ME 110, as viewed bythe network or other communication partners, rests solely on thetechnical specification of the security properties of the M2ME's TRE230, as in the case of simple smart card based authentication.

Therefore, the TRE 230 may also store a log of the validation processand its results in response to every event of autonomous validation(e.g., before a network access attempt). For example, the storedmeasurement log and the Platform Configuration Register (PCR) values maybe stored and used to protect the integrity of the M2ME 110 usingtrusted computing group principles.

This stored data may also be used for external audits since the dataconstitutes an audit record. The audit data is stored in a secureinternal archive, either within the TRE 230, or protected by the TRE230, such that it cannot be altered without such tampering beingdetectable. As a result, integrity protection of the data is provided.

Furthermore, the audit data is bound to the specific purpose for whichautonomous validation was invoked (e.g., the specific instance of therun of a network access protocol). This may be accomplished by includingdata which uniquely identifies the validation purpose in the audit data.

For example, shared secrets or credentials established in the accessprotocol may be attached to the audit data and a digital signature canbe applied by the TRE 230 to the produced data set to protect itsintegrity. An entity independent of the M2ME 110 may then request theaudit data at any later point in time. For instance, the entity mayrequest the audit data periodically to establish whether the M2ME 110 inquestion is trustworthy at every earlier network access event. Thisevidence together with identity credentials for the TRE 230 and M2ME 110may then be counter-checked with network-side protocols about networkaccess attempts to further validate the identity and trustworthiness ofthe TRE 230 and to detect tampering of the M2ME 110.

FIG. 4 shows a procedure 400 for the TRE 230 to perform asemi-autonomous validation of the integrity of an M2ME 110. When theprocedure 400 begins, the TRE 230 checks if it has achieved a predefinedstate of secure start-up, at 410. Next, the TRE 230 checks if apre-defined portion of the rest of the M2ME 110 that needs securestart-up has achieved a predefined state of secure start-up, at 420.Then, further checks may take place either by the TRE 230 itself or by ameasuring component in the M2ME 110 external to the TRE 230 butintegrity-protected by the TRE 230, at 430. In such later-stage checks,integrity of other components, configurations, or parameters of the restof the M2ME 110 is checked when they are loaded, started, or at anyother, pre-defined, run-time time event that is available to themeasuring component.

The remote entity such as PVA 150 may become indirectly aware of thefact that the M2ME 110 has passed a semi-autonomous validation test.There is explicit signaling to the network of the outcome of thevalidation. This signaling should originate from within the TRE 230 andshould be protected cryptographically, at 440. Furthermore, thesignaling precedes the M2ME 110 authentication required for MID downloadto ensure the integrity of the M2ME 110 component that is the target ofthe download. The signaling may also include evidence of the bindingbetween the TRE's authentication and the resources in the M2ME 110 usedfor actual validity checking. Such evidence may include a token sentfrom the M2ME 110 to the network that provides further information forestablishing certification of the TRE 230 and the M2ME 110.

FIG. 5 shows an alternative procedure 500 for semi-autonomous validationof the integrity of the TRE 230. The procedure 500 begins when the PVA150 or the SHO 140 requests the TRE 230 to perform validationperiodically, at 510. The request may be sent after the M2ME 110 isfirst registered or the request may be sent once the M2ME 110 isauthenticated for the very first time with the SHO.

Alternatively, the request may be sent periodically as a protectedoperation and maintenance (OAM) message from the PVA 150 or SHO 140. Theperiod of a ‘periodic re-validation’ may be relatively long but stillshort enough to make the SHO 140 feel safe about the ‘freshness’ of thevalidation.

Next the TRE 230 performs a validation procedure based on the request,at 520. Upon successful validation, the TRE 230 sends a validationresponse message to the PVA, which may include a time-stamp made by theTRE 230 indicating when the last validation took place, at 530.Alternatively, the TRE 230 may send a message stating that the lastvalidation took place before the expiry of the current round of periodicvalidation cycle.

It should be noted that there is no explicit signaling about the‘outcome’ of the validation, just some indirect indication, as part ofthe authentication request, indicating that the prescribed periodicvalidation really took place. This indication may be in the include thedate or time when this was carried out.

FIG. 6 is an example of a procedure 600 for remotely validating anM2ME's integrity. To begin the procedure 600, the M2ME 110 may start upto a pre-defined secure state, at 610. Upon achieving a secure state,the M2ME 110 may request that the TRE 230 generate evidence of theplatform validity, at 620. Next, the TRE 230 collects material to beused to produce such evidence from the rest of the M2ME 110, at 630. Forexample, the material may include security-critical executable code inthe M2ME 110, credentials for the M2ME's operation system (OS),equipment IDs, etc. Then, the TRE 230 generates the evidence for thevalidation of the M2ME 110 and cryptographically protects it forintegrity and/or confidentiality, at 640. Next, the TRE 230 passes theprotected evidence to the M2ME 110, at 650. The M2ME 110 forwards theprotected evidence to the PVA 150, at 660.

Upon receipt of the protected evidence, the PVA 150 evaluates theevidence and determines if the M2ME 110 is trustworthy enough to allowit to continue on to perform device authentication and to allow downloadof MIDs, at 670.

Optionally, some of the elements of the procedure described above may beintegrated with the process used for the M2ME authentication that is aprerequisite for the download of a MID. It should be noted, that thecommunication between the TRE 230 and the PVA 150 should be protected.

After any of the three validation procedures described above areperformed, a binding between M2ME validation and authentication isdesirable in many scenarios. In the case of an autonomous validation,the validation may be some certificate or credential of the M2ME 110which attests to the secure state of the M2ME 110. In the case of theother validation procedures, the validation may include more securemeans of certification of the secure state of the M2ME 110. Because theM2ME's TRE 230 is the trusted environment that assures the securityproperties of the M2ME-internal resources used to perform validation ofthe M2ME 110, there should be a binding of the credentials and/oroutcomes of validation to credentials used for authentication.

There are three procedures for authenticating a M2ME 110. First, as aprerequisite for initial network connectivity, a pristine M2ME 110 maybe authenticated by the ICF 160. Second, as a prerequisite for thedownload of a MID (e.g. a USIM application with its credentials), anM2ME 110 may be authenticated by an entity such as the DPF 180 to provethat it contains an authenticated TRE 230. Third, for operationalnetwork access (e.g., using a downloaded MID), the M2ME 110 may beauthenticated by the SHO 140.

Autonomous validation is the only type of validation that may be boundto the authentication procedures that are used for initial networkconnectivity, as described above. The other two validation methodsdescribed above require involvement of the PVA 150 but there is noinitial connectivity and it is not possible for the M2ME 110 to engagethe PVA 150 for validation.

For initial network connectivity, the binding of integrity/validity tonetwork access authentication may only be implicit for autonomousvalidation because no network-based checks of integrity/validity areperformed until after network attachment has occurred. For the other twoforms of validation, tokens (such as a digital certificate attesting tothe credentials and certification of the TRE 230) can be passed in theinitial attachment messages which provide further information on theidentity of the TRE 230 within the M2ME 110 and hence the securityfunctionality of the TRE 230 and integrity of the M2ME 110.

For operational connectivity, there may be semi-autonomous validation aswell as remote validation. Further, there may be binding of suchvalidation methods to the subsequent authentication steps. Two ways forachieving the binding of the platform validation and the authenticationare described below.

First, there may be a logical binding of the TRE 230 holding theauthentication credentials to the M2ME 110. During the authentication,the integrity of the device platform is validated. It should be notedthat earlier solutions on logical binding (e.g., SIM-lock) have beencircumvented quickly. However, there are other, newer methodologies thatmay be successfully applied such as TCG.

Second, there may be a physical binding of the TRE 230 to the M2ME 110.During the TRE 230 authentication, the integrity of the device platformis validated.

In both cases above, the actual validation of the platform resourcesshould be performed either by using functionality of a hardware securitycomponent securely embedded into the M2ME 110 (i.e., the embedded TRE)or by using such hardware security components that may be outside of theTRE 230 but whose security properties are assured by the TRE 230 andwhich have a secure connection to the TRE 230. It should be noted, thatthe credentials and the application used for 3GPP AKA authentication arenot designed for the purpose of validating the binding of a securehardware component in the hosting device.

The steps of validation and authentication may be combined in a sessionof a common protocol. For example, the 3GPP uses the IKEv2 as a methodto combine authentication steps for a device and a hosting-party. Thesame protocol may also be considered for use in a combinedvalidation/authentication procedure.

FIG. 7 shows a first example procedure 700 for provisioning andre-provisioning of a MID to the M2ME 110 in case of authenticatedaccess. While this procedure is provided for purposes of example, otherinteractions between network entities, are possible with a similarresult. In FIG. 7, arrows indicate connections between the functions,service providers, and validation authorities. A solid arrow indicatesthe air interface for the initial network access from the M2ME 110 tothe VNO 115, the dashed arrows indicate the connections between the M2ME110 and the ICF 160 via the air interface provided by the VNO's network,and the dotted arrows indicate the connections between the M2ME 110 andthe DPF 180, DPF 170 and the PVA 150, over the air interface of theVNO's network and the IP connectivity provided by the ICF 160. While theICF 160, DRF 170, and DPF 180, are all shown as individual entities, oneof skill in the art would recognize that they could also be locatedwithin in one single entity as shown in FIG. 1 or in some otherarrangement which achieves essentially the same functionality.

In the procedure 700 of FIG. 7, the downloading and provisioning of MIDto a M2ME 110 may occur when the M2ME 110 accesses a 3G VNO's network inits initial network access. The VNO 115 provides an air interface to theM2ME 110 according to the following procedure.

The M2ME 110 may use the standard GSM/UMTS principle (GPRS/PS), forexample, to decode network information and attach to the network of theVNO 115 using an attach message. In the attach message, the M2ME 110sends a provisional M2ME ID, or PCID to the VNO 115 and the M2ME 110 isauthenticated by the standard UMTS AKA procedure by the VNO 115, at 701.The content and structure of the PCID is such that the VNO 115recognizes it as an IMSI.

It should be noted, in order to be able to perform client authenticationfor initial attachment to the VNO's network, the M2ME 110 needs tosupport an authentication algorithm, such as the Milenage algorithm,which is shared by all the M2MEs and the VNO 115.

The VNO 115, recognizing the PCID as an ID for the M2ME 110, contactsthe ICF 160 that will accept the PCID as a legitimate preliminarycredential, at 702. Then, the ICF 160 issues a set of preliminaryauthentication vectors (AV) to protect further communication with theM2ME 110, and starts to provide protected IP connectivity to the M2ME110, at 703. This communication is performed using the air interfaceprovided by the VNO's network.

Next, the M2ME 110 and the ICF 160 perform the standard AKA process toproduce preliminary AKA keys to protect the communication from/to theM2ME 110, at 704. Afterwards and until the M2ME 110 connects to thenetwork using the SHO's MID credentials after downloading andprovisioning them, all communication between the M2ME 110 to the variousnetwork entities is done via the air interface provided by the VNO'snetwork and the IP connectivity and encryption protection provided bythe ICF 160.

The ICF 160 then redirects the M2ME 110 to the DPF 180. In doing so, theICF 160 may send the PCID to the DRF 170, at 705. Then the DRF 170 aidsthe M2ME 110 to find the SHO 140, at 706. Next, the DRF 170 connects tothe SHO 140 and registers the M2ME 110 for connection to the SHO'snetwork, at 707. In response, the SHO 140 requests the PVA 150 tovalidate the authenticity and integrity of the TRE 230 of the M2ME 110,at 708. Then the PVA 150 validates the authenticity and integrity of theTRE 230 of the M2ME 110, at 709. The validation procedure may beperformed in a manner similar to the validation procedures describedabove with respect to FIGS. 3-5.

Upon completing a validation, the PVA 150 sends the validation resultsback to the SHO 140, at 710. The SHO 140 contacts the DPF 180 andauthorizes provisioning of the MID (USIM/ISIM application) to the M2ME110, at 711.

Next, the DPF 180 downloads a MID object to the M2ME 110, at 712. Thenthe M2ME 110 provisions the downloaded MID into the TRE 230 and reportsthe success/failure status of the provisioning to the DPF 180, at 713.The M2ME 110 may need to send a token that can be used for verificationof such a message. Such a token would need to be in a form that isresistant to tampering and replay attacks. Finally, the DPF 150 reportsthe success/failure status of the provisioning back to the SHO 140, at714.

FIG. 8 shows another procedure 800 for provisioning and re-provisioningof a MID to the M2ME 110 in case of authenticated access. In thisprocedure 800, the downloading and provisioning of MID to the M2ME 110may occur when the M2ME 110 accesses a 3G VNO's network in its initialnetwork access. The ICF 160 requests a PVA 150 to validate the TRE 230of the M2ME 110 before releasing provisional authentication vectors tothe M2ME 110 and also before allowing an IP connectivity to the M2ME 110instead of having the TRE 230 validation take place prior to the SHO 140authorizing the downloading and provisioning of its MID.

The procedure 800 begins when the M2ME 110 uses, for example, thestandard GSM/UMTS principle (GPRS/PS) to decode network information andattach to the network of the VNO 115, at 801. In the attach message theM2ME 110 sends a PCID to the VNO 115. The M2ME 110 is authenticated bythe standard UMTS AKA procedure by the VNO 115.

The VNO 115, recognizing the PCID for an M2ME 110, contacts an ICF 160that will accept the PCID as a legitimate preliminary credential, at802. Next, the ICF 160 requests the PVA 150 to validate the authenticityand integrity of the TRE 230 of the M2ME 110, at 803. Then the PVA 150validates the authenticity and integrity of the TRE 230 of the M2ME 110,at 804. The validation may be performed using one of the previouslymentioned validation procedures.

Once the PVA 150 sends the validation results back to the ICF 160, at805, the ICF issues a set of preliminary authentication vectors (AV) toprotect further communication with the M2ME 110, and starts to provideprotected IP connectivity to the M2ME 110, at 806. This communication isdone via the air interface provided by the VNO's network.

Next, the M2ME 110 and the ICF 160 perform the standard AKA process toproduce preliminary AKA keys to protect the communication from/to theM2ME 110, at 807. Afterwards and until the M2ME 110 connects to thenetwork using SHO's U(I)SIM credentials after downloading andprovisioning them, all communication between the M2ME 110 to the variousnetwork entities is done via the air interface provided by the VNO'snetwork and the IP connectivity and encryption protection provided bythe ICF 160.

Then the ICF 160 directs the M2ME 110 to a DRF 170, at 808. In doing so,the ICF 160 sends the PCID as well as information about the TREvalidation status to the DRF 170. The DRF 170 aids the M2ME 110 to findits SHO 140 and redirects the M2ME 110 to the SHO 140, at 809. The DRF170 then connects to the SHO 140 and registers the M2ME 110 forconnection to the SHO 140, at 810. In doing so, the DRF 170 also conveysto the SHO 140 information about the TRE validation status.

After reviewing the TRE validation status information it received fromthe DRF 170, the SHO 140 contacts the DPF 180 and authorize provisioningof the MID (USIM/ISIM application) into the M2ME 110, at 811. Inresponse, the DPF 180 downloads a MID (U(I)SIM application andcredentials) object to the M2ME 110, at 812.

The M2ME 110 provisions the downloaded MID into the TRE 230 and reportsthe success/failure status of the provisioning to the DPF 180, at 813.The M2ME 110 may send a token that can be used for verification of suchmessage. Such a token should be in a form that is resistant to tamperingand replay attacks. Finally, the DPF 180 reports the success/failurestatus of the provisioning back to the SHO 140.

FIG. 9 is an example flow diagram of a procedure 900 for reprovisioningthe M2ME 110 for a new SHO (not shown). The procedure 900 begins whenthe M2ME owner contacts the New SHO to transfer the M2ME parameters, at910. Then the M2ME Owner contacts the M2ME to initiate a re-provisioningprocedure, at 920.

The New SHO requests a validation entity to validate the M2ME 110, at930. The PVA 150 then validates the M2ME 110 and sends success/failuremessage to the New SHO, at 940. Upon receiving notice of a success, theNew SHO requests a DPF to download/provision the New MID (ie. USIMapplication and credentials) to the M2ME 110, at 950.

Then the DPF 180 securely downloads the New MID package to the M2ME 110,at 960. The M2ME 110 sends a message to the Old SHO that the Old MID hasbeen discarded, at 970. Then, the Old SHO sends an ACK to the M2ME 110which the M2ME 110 then forwards to the DPF 180 and then the New SHO, at980

The M2ME 110 updates its system and installs the MID with the help ofthe DPF 180 and sends a success/failure message back to the DPF 180, at990. The DPF 180 reports the success/failure message to the New SHO, at992. Upon success the provisioning process is completed, at 998.

In another reprovisioning procedure, the M2ME 110 may be put in apristine state and re-initiate the same type of process as the initialprovisioning procedures described in FIGS. 7 and 8.

In another embodiment, the PVA 150 is responsible for ensuring that anysoftware (SW) or firmware (FW) update performed while the M2ME 110 isstill subscribed to the same SHO 140, will be done in a secure manner.This includes updating or re-configuring credentials.

This means that the PVA 150 or DPF 180 should supervise procedures suchas secure over-the-air (and also on-wire) downloading of SW/FW andre-provisioning of the M2ME 110 and/or the TRE 230. Therefore, the PVA150 or DPF 180 may employ such available methods as the ones provided inthe OMA DM and OMA FOTA specifications, for secure downloading, FLASHupdate, and/or device reconfiguration of the M2ME 110.

Additionally, because the M2ME's trust state information can changed dueto a remote SW/FW update or reconfiguration, PVA 150 or DPF 180 shouldbe able to initiate and obtain the results of either a new verifiableboot or a run-time trust-state information check of the M2ME 110 or theTRE 230 upon completion of the SW/FW update or reconfiguration. The PVA150 or DPF 180, should also update its own database of the trust stateinformation about the M2ME 110. In case the DPF 180 is responsible forthe remote SW/FW update or remote credentials reconfiguration, anypredicted effect of the update/reconfiguration on the ‘trust state’information about the M2ME 110 must be sent from the DPF 180 to the PVA150, so that the PVA 150 can update its database of the ‘trust state’information for the M2ME 110.

Additionally, solutions for detection of and post-detection remedialreaction against tampering of the M2ME 110 are disclosed. In order tomake the M2ME 110 less vulnerable to tampering attack, several solutionsare proposed.

First, the M2ME 110 may be configured to have functionality whereby itcan detect certain types of ‘tampering’ done to it or any sub-system(s)within it on a sufficiently frequent (in case of regularly scheduleddetection attempts) and/or timely (in case of event-driven detectionattempts) basis. Examples of such detectable tamper events may includebut are not limited to: (1) remediable and/or un-remediable compromiseof the OS by malware or viruses; (2) buffer overflow events; (3) suddenunexpected or unauthorized changes in radio or higher-layer connectivitycharacteristics and/or environmental readings; (3) excessively repeatedfailure and/or denial of access or service by trusted network elementsfor the M2ME's requests for preliminary authentication, registration, orMID provisioning; or (4) any unexpected/unauthorized change in apost-boot or run-time reading of ‘trust state’ of the M2ME 110 or M2MEsubsystem relating to remote MID management functionality. NetworkElements such as the PVA 150, ICF 160, or any other network elementsdescribed in FIG. 1 may also be configured to detect tampering. Forexample, the network elements may be configured to remotely detect,using its own functions and/or functions of the M2ME 110 certain typesof ‘tampering’ done to the M2ME 110. Additionally, the network elementsmay be configured to request the M2ME 110 to report on anytamper-detection event.

Upon self-detection of any tampering on itself, the M2ME 110 should takesteps to limit further damage to it or other network elements. Forexample, upon detection of tampering, the M2ME 110 may be configured todisable functions related to remote MID management. The M2ME 110 mayalso be configured to disable access by internal resources (such as SWor certain parts of the OS) of the M2ME 110 to pre-designated highlysensitive areas of the M2ME 110 such as the TRE 230, or other portionsof the M2ME 110 that hold remote-MID-management related data, code, orcredentials, such as the SIM and/or TPM/MTM.

Upon self-detection of tampering, the M2ME 110 may also be configured tosend to a designated network element (such as a PVA) a report of thesuspected or detected tamper event as well as the event of thepost-detection self-remedial or re-active action the M2ME 110 took. Itshould be noted that such an event report may also include a timestampof the events or even a location-information stamp of the events such asthe most current GPS reading of the M2ME 110 or a list of theneighboring cells.

Also upon detection of tampering, the M2ME 110 may be configured toperform remedial actions such as deleting, quarantining, or uninstallingrecent SW updates, or suspected viruses or malware codes or data. TheM2ME 110, may also be configured to delete any pre-designated set ofdata related to remote MID management functions, such as USIM relatedkeys or credentials, from transient (e.g. RAM) and/or persistent (e.g.NVRAM, Flash, Hard Disk, SIM, TPM/MTM internal or encrypted storageareas, etc) storage.

Finally, upon detection of tampering, the M2ME 110 may also beconfigured to power down the M2ME 110 or the part/subsystem of theterminal handling the remote MID management functionality.

Certain network elements such as the PVA 150 may also be responsible forand capable of initiating and performing remote ‘post-detection’reactive actions on behalf of the M2ME 110 that (1) has either reporteda suspected or detected tampering event, or (2) is suspected, by the PVA150 itself or other network elements that interacted with it, to haveexperienced a tampering event.

The features and embodiments described above are applicable to otherauthentication protocols than those needed for authentication for 3GUMTS network access. Examples of such protocols may include, but are notlimited to, those complying to the generic bootstrapping architecture(GBA) which is used for application-layer authentication, and theextensible authentication protocol based on SIM (EAP-SIM) forauthentication of GSM/UMTS terminals to non-3G access networks. Forexample, the network elements described in FIG. 1 may exist and performsimilar or same functions so as to allow authentication and remotemanagement of the identity and authentication of M2ME devices forservices, applications, or (non-3G) network accesses.

Although features and elements are described above in particularcombinations, each feature or element can be used alone without theother features and elements or in various combinations with or withoutother features and elements. The methods or flow charts provided hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable storage medium for execution by ageneral purpose computer or a processor. Examples of computer-readablestorage mediums include a read only memory (ROM), a random access memory(RAM), a register, cache memory, semiconductor memory devices, magneticmedia such as internal hard disks and removable disks, magneto-opticalmedia, and optical media such as CD-ROM disks, and digital versatiledisks (DVDs).

Suitable processors include, by way of example, a general purposeprocessor, a special purpose processor, a conventional processor, adigital signal processor (DSP), a plurality of microprocessors, one ormore microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs), FieldProgrammable Gate Arrays (FPGAs) circuits, any other type of integratedcircuit (IC), and/or a state machine.

A processor in association with software may be used to implement aradio frequency transceiver for use in a wireless transmit receive unit(WTRU), user equipment (UE), terminal, base station, radio networkcontroller (RNC), or any host computer. The WTRU may be used inconjunction with modules, implemented in hardware and/or software, suchas a camera, a video camera module, a videophone, a speakerphone, avibration device, a speaker, a microphone, a television transceiver, ahands free headset, a keyboard, a Bluetooth® module, a frequencymodulated (FM) radio unit, a liquid crystal display (LCD) display unit,an organic light-emitting diode (OLED) display unit, a digital musicplayer, a media player, a video game player module, an Internet browser,and/or any wireless local area network (WLAN) or Ultra Wide Band (UWB)module.

EMBODIMENTS

1. A method for performing Machine-to-Machine (M2M) communication.

2. A method as in any one of the preceding embodiments, whereincommunication includes one or more of authenticating, provisioning, orre-provisioning.

3. A method as in any one of the preceding embodiments, furthercomprising:

connecting, at a M2M-enabled equipment (M2ME), to a visited networkoperator's (VNO's) network.

4. A method as in any one of the preceding embodiments, furthercomprising:

receiving authorization to connect to a selected home operator's (SHO's)network.

5. A method as in any one of the preceding embodiments, furthercomprising:

connecting to the SHO's network.

6. A method as in any one of the preceding embodiments, wherein the VNOis a single network entity.

7. A method as in any one of the preceding embodiments, wherein the VNOincludes a plurality of network entities.

8. A method as in any one of the preceding embodiments, wherein the VNOis any access network that is accessed for the purpose of initialregistration and provisioning.

9. A method as in any one of the preceding embodiments, whereinregistration and provisioning includes registration and provisioning ofUSIM/ISIM applications.

10. A method as in any one of the preceding embodiments, furthercomprising:

the M2ME registering with a SHO that is not the VNO; and

the VNO remaining a VNO.

11. A method as in any one of the preceding embodiments, furthercomprising:

The M2ME registering with a SHO that is the VNO; and

The VNO becoming a SHO.

12. A method as in any one of the preceding embodiments, wherein the VNOis responsible for providing temporary network access to the M2ME.

13. A method as in any one of the preceding embodiments, where temporarynetwork access is based on temporary network access credentials.

14. A method as in any one of the preceding embodiments, whereintemporary network access credentials include a PCID or any othertemporary private ID.

15. A method as in any one of the preceding embodiments, furthercomprising:

the VNO providing open network access to the discovery and registrationfunction (DRF).

16. A method as in any one of the preceding embodiments, wherein nocredentials or authentication are required for access to the services ofat least the DRF.

17. A method as in any one of the preceding embodiments, wherein the VNOprovides open network access to the DRF when the VNO will become theSHO.

18. A method as in any one of the preceding embodiments, furthercomprising:

the VNO providing full network access using provisioned USIM/ISMapplications.

19. A method as in any one of the preceding embodiments, wherein fullnetwork access includes IMS.

20. A method as in any one of the preceding embodiments, wherein a ROincludes one or more of an ICF, a DRF, and a downloading andprovisioning function (DPF).

21. A method as in any one of the preceding embodiments, wherein theICF, the DRF, and the DPF are each located in a separate entity.

22. A method as in any one of the preceding embodiments, wherein the ICFis responsible for the validation of credentials that allow temporaryaccess to communication networks for the purpose of registration andprovisioning of operational network access.

23. A method as in any one of the preceding embodiments, furthercomprising:

the ICF issuing temporary network access credentials.

24. A method as in any one of the preceding embodiments, furthercomprising:

the ICF issuing a temporary private identifier for the M2ME.

25. A method as in any one of the preceding embodiments, whereintemporary network access credentials or a temporary private identifierare used for authenticated initial temporary network access.

26. A method as in any one of the preceding embodiments, furthercomprising:

The ICF provisioning the M2ME with one or more of M2M keys,configurations, and applications.

27. A method as in any one of the preceding embodiments, whereinprovisioning includes over the air provisioning.

28. A method as in any one of the preceding embodiments, furthercomprising:

the ICF providing credentials to the equipment supplier (E/S) topre-configure the M2ME.

29. A method as in any one of the preceding embodiments, wherein the ICFis configured to provide secure transmission of credentials to theorganization that is responsible for embedding them into the M2ME.

30. A method as in any one of the preceding embodiments, furthercomprising:

the ICF registering credentials in a database.

31. A method as in any one of the preceding embodiments, furthercomprising:

the ICF receiving a request to validate credentials from a third party;and

the ICF performing credentials validation.

32. A method as in any one of the preceding embodiments, whereincredentials validation includes secure transmission of authenticationvectors to a third party.

33. A method as in any one of the preceding embodiments, whereinauthentication vectors includes related data.

34. A method as in any one of the preceding embodiments, wherein allaccess networks are considered visited networks prior to successfulregistration of the M2ME to the SHO.

35. A method as in any one of the preceding embodiments, wherein theM2ME connects to the SHO transparently through a conventional networkwithout network changes.

36. A method as in any one of the preceding embodiments, wherein the DRFenables the after-purchase selection of a specific SHO, and registrationof the M2ME with the selected SHO.

37. A method as in any one of the preceding embodiments, wherein the DRFis an independent service.

38. A method as in any one of the preceding embodiments, wherein the DRFis operated by a SHO.

39. A method as in any one of the preceding embodiments, wherein theSHO's RO may be contacted via the SHO's 3GPP network.

40. A method as in any one of the preceding embodiments, wherein theSHO's RO may be contacted via the Internet.

41. A method as in any one of the preceding embodiments, wherein theSHO's RO is discoverable.

42. A method as in any one of the preceding embodiments, wherein theSHO's RO is discoverable using functionality in the M2ME.

43. A method as in any one of the preceding embodiments, wherein the DRFallows the customer to select the SHO after delivery of the M2ME.

44. A method as in any one of the preceding embodiments, wherein the DRFallows the M2ME to have an IP connection to the RO using eithertemporary authenticated network access or limited open network access.

45. A method as in any one of the preceding embodiments, wherein the DRFallows the M2ME to request USIM/ISM application provisioning via a VNO.

46. A method as in any one of the preceding embodiments, furthercomprising:

the DRF approving a provisioning request; and

-   -   authorizing a DPF to provision the M2ME.

47. A method as in any one of the preceding embodiments, wherein the DRFsupports registration of the M2ME by the owner of the M2ME.

48. A method as in any one of the preceding embodiments, wherein the DRFsupports association of the M2ME with a SHO.

49. A method as in any one of the preceding embodiments, furthercomprising:

validating, via the PVA, the authenticity of the TRE using the M2ME'scredentials.

50. A method as in any one of the preceding embodiments, furthercomprising:

the DRF generating a package of data to be transmitted to the M2ME.

51. A method as in any one of the preceding embodiments, furthercomprising:

the DRF obtaining a package of data to be transmitted to the M2ME.

52. A method as in any one of the preceding embodiments, furthercomprising:

the DRF transmitting data securely to the PS.

53. A method as in any one of the preceding embodiments, furthercomprising:

the DPF generating a package of data to be transmitted to the M2ME.

54. A method as in any one of the preceding embodiments, furthercomprising:

the DPF obtaining a package of data to be transmitted to the M2ME.

55. A method as in any one of the preceding embodiments, furthercomprising:

the DPF transmitting data securely to the PS.

56. A method as in any one of the preceding embodiments, furthercomprising:

the DRF facilitating the setting up of a security association betweenthe M2ME and the DPF.

57. A method as in any one of the preceding embodiments, furthercomprising:

the DRF generating and transmitting security tokens to the M2ME and theDPF over secure channels.

58. A method as in any one of the preceding embodiments, wherein the DPFenables the remote provisioning of USIM/ISM credentials to the M2ME.

59. A method as in any one of the preceding embodiments, furthercomprising:

The DPF receiving authorization from the DRF to provision the M2ME.

60. A method as in any one of the preceding embodiments, whereinreceiving authorization includes the DPF receiving a security token forcommunicating with the M2ME.

61. A method as in any one of the preceding embodiments, furthercomprising:

the DPF receiving an application package from the DRF.

62. A method as in any one of the preceding embodiments, furthercomprising:

the DPF generating an application package from stored rules; and

advising the DRF of credentials that have been downloaded to the DRF.

63. A method as in any one of the preceding embodiments, wherein the DPFis configured to support the provisioning of a USIM/ISM application orUSMI/ISIM parameters to the M2ME.

64. A method as in any one of the preceding embodiments, wherein the DPFis configured to perform future updates to a USIM/ISIM application orUSIM/ISIM parameters to the M2ME.

65. A method as in any one of the preceding embodiments, wherein the DPFis configured to perform future provisioning of new applications.

66. A method as in any one of the preceding embodiments, wherein the DPFis configured to notify the DRF of a successful or unsuccessfulprovisioning event.

67. A method as in any one of the preceding embodiments, wherein the SHOis the network operator which has a commercial relationship with theuser of the M2ME.

68. A method as in any one of the preceding embodiments, wherein the SHOis responsible for billing the customer.

69. A method as in any one of the preceding embodiments, wherein the SHOperforms the role of the DRF.

70. A method as in any one of the preceding embodiments, wherein the SHOperforms the role of the DPF.

71. A method as in any one of the preceding embodiments, wherein the SHOperforms other roles.

72. A method as in any one of the preceding embodiments, wherein the SHOhas an operational relationship with the DRF and DPF.

73. A method as in any one of the preceding embodiments, wherein the DRFand the DPF have an operation relationship with each other.

74. A method as in any one of the preceding embodiments, wherein theM2ME is initially not commissioned to operate with a service provider.

75. A method as in any one of the preceding embodiments, wherein theM2ME, in communication with the VNO, establishes a channel to the RO.

76. A method as in any one of the preceding embodiments, wherein a M2MEhas a private identity.

77. A method as in any one of the preceding embodiments, wherein a PCIDis a private identity.

78. A method as in any one of the preceding embodiments, wherein aprivate identity enables any VNO to recognize the M2ME, to permittemporary access to the VNO's services, and to direct the initialconnectivity messages to the appropriate network components in order todownload and provision service with an operator.

79. A method as in any one of the preceding embodiments, wherein the PVAis responsible for credentials that attest to the authenticity of thesecure device within the M2ME that is used for storage and execution ofdownloaded USIM/ISIM applications.

80. A method as in any one of the preceding embodiments, wherein the PVAincludes one or more commercial organizations who issue credentials andprovide credential validation services.

81. A method as in any one of the preceding embodiments, whereincredentials include certificates and key pairs.

82. A method as in any one of the preceding embodiments, wherein thesecure device within the M2ME is one or more of a UICC, a TRE, or someother secure module.

83. A method as in any one of the preceding embodiments, wherein the PVAfunction is required where strong authentication of the secure device isa prerequisite for the provisioning of the USIM/ISIM applications.

84. A method as in any one of the preceding embodiments, furthercomprising:

creating and issuing credentials to attest to the security of a securedevice within the M2ME.

85. A method as in any one of the preceding embodiments, wherein thecreating and issuing of credentials to attest to the security of asecure device within the M2ME are performed by the PVA.

86. A method as in any one of the preceding embodiments, wherein the PVAis configured to provide validation the credentials for the securedevice within the M2ME.

87. A method as in any one of the preceding embodiments, wherein the PVAis configured to provide for maintenance of data relating to thevalidity of issued credentials.

88. A method as in any one of the preceding embodiments, wherein theequipment supplier (E/S) securely obtains credentials from the ICF forauthentication of for temporary initial network access.

89. A method as in any one of the preceding embodiments, wherein the E/Sis configured to support re-configuration of the M2ME.

90. A method as in any one of the preceding embodiments, whereinre-configuration includes provisioning the M2ME with preliminarynetwork-access credentials.

91. A method as in any one of the preceding embodiments, wherein the E/Sis configured to obtain securely from a PVA 150 the credentials for usein proving to the DRF 170, via the ICF 160, that the M2ME complies witha standardized set of security requirements.

92. A method as in any one of the preceding embodiments, wherein the E/Sis configured to configure the M2ME with credentials.

93. A method as in any one of the preceding embodiments, wherein the E/Sis configured to provide a means for the M2ME owner to select a desiredDRF and SHO.

94. A method as in any one of the preceding embodiments, wherein the E/Sis configured to provide for automatic DRF and SHO selection to occurwhen the M2ME is connected to an access network.

95. A method as in any one of the preceding embodiments, wherein an M2MEincludes one or more of a transmitter, a receiver, a processor, atrusted environment (TRE), a global positioning system (GPS), asubscriber identity module (SIM), and a secure time unit.

96. A method as in any one of the preceding embodiments, wherein theM2ME is configured to support many different trust mechanisms.

97. A method as in any one of the preceding embodiments, wherein theM2ME is configured to support one or more of TRE, SIM, or ISIM.

98. A method as in any one of the preceding embodiments, wherein trustmechanisms are fully integrated into common AKA protocols.

99. A method as in any one of the preceding embodiments, wherein commonAKA protocols include one or more of trust state information, or keysprotected by the TRE.

100. A method as in any one of the preceding embodiments, wherein AKAprotocols protect any communication between the M2ME and a networkelement before full AKA can take place and after authentication has beenestablished.

101. A method as in any one of the preceding embodiments, wherein theSIM is enhanced to include the functions of a trusted processing module(TPM) or mobile trusted module (MTM).

102. A method as in any one of the preceding embodiments, wherein theSIM is configured to operate closely with a TPM or MTM.

103. A method as in any one of the preceding embodiments, wherein theTRE is configured to perform the functionality of the SIM.

104. A method as in any one of the preceding embodiments, wherein theM2ME is provisioned with an AKA root secret.

105. A method as in any one of the preceding embodiments, wherein theroot secret is provisioned by the E/S.

106. A method as in any one of the preceding embodiments, wherein theroot secret is protected by the USIM.

107. A method as in any one of the preceding embodiments, wherein theroot secret never changes.

108. A method as in any one of the preceding embodiments, wherein theprocessor is configured to derive session keys from the AKA root secret.

109. A method as in any one of the preceding embodiments, wherein theM2ME is configured to provide trust state information to the ICF.

110. A method as in any one of the preceding embodiments, wherein thetrust state information may be used for preliminary authentication whenthe M2ME attaches to the VNO.

111. A method as in any one of the preceding embodiments, wherein truststate information is used to derive session keys.

112. A method as in any one of the preceding embodiments, wherein nrefers to the index for the most current update of the session keysCK_(n) and IK_(n) and CKn=f3K (RAND∥PCR0n), IKn=f4K (RAND∥PCR0 n) wheref3_(K)( ) and f4_(K)( ) refer to the AKA key derivation functions forthe cipher key and integrity key, respectively, out of the shared mastersecret K, RAND is the random nonce within the Authentication Vector (AV)generated by the CATNA and sent to, and thus shared by, the M2ME 110 inthe AKA process, and PCR0_(n) refers to the most current value of thePCR0 register inside an MTME on the M2ME 110.

113. A method as in any one of the preceding embodiments, wherein thecurrent value of PCR0 register signifies a description of the mostrecent post-boot trust status of the M2ME.

114. A method as in any one of the preceding embodiments, wherein thevalues of CK_(n) and IK_(n) change when the value of PCR0 changesbetween boots.

115. A method as in any one of the preceding embodiments, wherein theICF is aware of changes to the trust state of the M2ME.

116. A method as in any one of the preceding embodiments, whereinchanges to the trust state of the M2ME include changes to the value ofPCR0.

117. A method as in any one of the preceding embodiments, wherein theICF is notified of the schedule and substance of updates to the M2ME'sOS, firmware, or applications.

118. A method as in any one of the preceding embodiments, wherein theICF is notified of any change to the M2ME that affects the trust stateof the M2ME.

119. A method as in any one of the preceding embodiments, wherein AKAciphering and integrity keys shared between the M2ME and the ICF areupdated and made useful for authentication of the M2ME.

120. A method as in any one of the preceding embodiments, wherein thesession keys reflect the most current trust state value of the M2ME.

121. A method as in any one of the preceding embodiments, wherein thesession keys enhance security of the AKA key derivation process.

122. A method as in any one of the preceding embodiments, wherein theTRE is a logically separate area in the M2ME.

123. A method as in any one of the preceding embodiments, wherein thereis hardware support for the logical separation of the TRE.

124. A method as in any one of the preceding embodiments, wherein theTRE is a removable module.

125. A method as in any one of the preceding embodiments, wherein theTRE is a non-removable module.

126. A method as in any one of the preceding embodiments, wherein theTRE functions with an integrated circuit (IC).

127. A method as in any one of the preceding embodiments, wherein theTRE functions are distributed across a plurality of ICs.

128. A method as in any one of the preceding embodiments, wherein theTRE defines logical and physical interfaces to the outside world.

129. A method as in any one of the preceding embodiments, wherein theinterfaces exposed by the TRE are usable under the control of anauthorized entity.

130. A method as in any one of the preceding embodiments, wherein theTRE provides a root of trust for the secure storage and secure executionenvironment for multiple management identities (MIDs).

131. A method as in any one of the preceding embodiments, wherein theTRE provides for provisioning and managing MIDs.

132. A method as in any one of the preceding embodiments, wherein a MIDis a secure application.

133. A method as in any one of the preceding embodiments, wherein a MIDincludes one or more of a subscription management function, a securepayment application, a subscription management identity, a USIMapplication, an ISIM application, a virtual SIM (vSIM), or a dynamicsecurity identity solution.

134. A method as in any one of the preceding embodiments, wherein theTRE is provisioned in a secure, out-of-band facility with any requiredcryptographic keys and other credentials.

135. A method as in any one of the preceding embodiments, wherein theTRE provides protection against physical and logical attacks.

136. A method as in any one of the preceding embodiments, wherein theTRE enforces its own security policy.

137. A method as in any one of the preceding embodiments, wherein theTRE is sufficiently secure to allow the storage and execution of MIDs.

138. A method as in any one of the preceding embodiments, wherein theTRE has interfaces to parts of the M2ME that are outside the TRE.

139. A method as in any one of the preceding embodiments, wherein theTRE has an embedded unique identiy.

140. A method as in any one of the preceding embodiments, wherein theidentity of the TRE is associated with the identity of the M2ME.

141. A method as in any one of the preceding embodiments, wherein theTRE is configured to securely authenticate its identity to issuingauthorities using standard protocols.

142. A method as in any one of the preceding embodiments, wherein theTRE is implemented in an UICC.

143. A method as in any one of the preceding embodiments, wherein theTRE is implemented as an integrated solution on the M2ME using hardwareand software components provided by the M2ME.

144. A method as in any one of the preceding embodiments, wherein theTRE supports downloading and remote provisioning and management of MIDs.

145. A method as in any one of the preceding embodiments, wherein theTRE supports the functionally of the management identity executable(MIDE).

146. A method as in any one of the preceding embodiments, wherein theM2ME supports integrity checks of the software code and data that makeup the TRE code base.

147. A method as in any one of the preceding embodiments, wherein theTRE is checked at power up/boot-time of the M2ME.

148. A method as in any one of the preceding embodiments, wherein codechecks are conducted during operation use of the M2ME.

149. A method as in any one of the preceding embodiments, wherein codechecks are performed as a background process at defined intervals or atcertain triggers.

150. A method as in any one of the preceding embodiments, wherein thecode checks cover a partial or full check of the M2ME.

151. A method as in any one of the preceding embodiments, wherein theTRE includes support for multiple isolated, trusted domains.

152. A method as in any one of the preceding embodiments, wherein eachdomain is owned by a stakeholder-owner.

153. A method as in any one of the preceding embodiments, wherein eachdomain is isolated from other domains.

154. A method as in any one of the preceding embodiments, wherein eachdomain is protected against tampering and unauthorized access.

155. A method as in any one of the preceding embodiments, wherein theTRE provides inter domain services.

156. A method as in any one of the preceding embodiments, whereininter-domain services include one or more of authentication andattestation functionality.

157. A method as in any one of the preceding embodiments, wherein theM2ME connects to a network sporadically or infrequently.

158. A method as in any one of the preceding embodiments, wherein theM2ME operates in a dormant state.

159. A method as in any one of the preceding embodiments, whereinrun-time integrity checks of the TRE's software code are configured totake place while the M2ME operates in a dormant state.

160. A method as in any one of the preceding embodiments, whereinintegrity checks do not interfere with other M2ME or TRE processes.

161. A method as in any one of the preceding embodiments, wherein thestatus of integrity checks is ready when the M2ME connects to the SHO.

162. A method as in any one of the preceding embodiments, wherein theM2ME is assigned a temporary private identity that is unique to theM2ME.

163. A method as in any one of the preceding embodiments, wherein a PCIDis valid for a time limited validity period.

164. A method as in any one of the preceding embodiments, wherein thevalidity period is enforced by the M2ME.

165. A method as in any one of the preceding embodiments, wherein thevalidity period is controlled by the TRE.

166. A method as in any one of the preceding embodiments, furthercomprising:

removing the PCID.

167. A method as in any one of the preceding embodiments, wherein a PCIDmay be used by more than one M2ME, but not at the same time.

168. A method as in any one of the preceding embodiments, wherein PCIDsare systematically reallocated.

169. A method as in any one of the preceding embodiments, wherein aplurality of PCIDs are provisioned to an M2ME.

170. A method as in any one of the preceding embodiments, wherein M2MEsare released in groups of size N.

171. A method as in any one of the preceding embodiments, wherein M2MEsof the jth batch are referred to as M_i,j where j=1, . . . , M.

172. A method as in any one of the preceding embodiments, wherein PCIDassignment may be initialized with a matrix (P)_{i,j} of size N×M.

173. A method as in any one of the preceding embodiments, wherein theM2ME M_i,1 gets column P_i,* loaded into the TRE during manufacture.

174. A method as in any one of the preceding embodiments, wherein asecure timer or monotonic counter is initialized, activated, and putunder control of the TRE.

175. A method as in any one of the preceding embodiments, wherein theM2ME M_i,1, uses P_i,1 for a determined time span T or a predeterminednumber of times based on the time or counter that was initialized.

176. A method as in any one of the preceding embodiments, wherein theTRE discards P_i,1 and uses P_i,2.

177. A method as in any one of the preceding embodiments, wherein thenetwork is configured to determine where a device is in a lifetimecycle.

178. A method as in any one of the preceding embodiments, whereinhandling the PCID column vector with the TRE and enforcement of timelimits by the TRE prevents concurrent use of PCIDs and ensures that theM2ME has a valid PCID throughout its operation time.

179. A method as in any one of the preceding embodiments, wherein theM2ME is configured to re-provision PCIDs.

180. A method as in any one of the preceding embodiments, wherein atleast two M2MEs try to use the same PCID at the same time.

181. A method as in any one of the preceding embodiments, wherein thenumber of PCIDs is much larger than the number of M2MEs in a batch.

182. A method as in any one of the preceding embodiments, wherein a PCIDis chosen randomly.

183. A method as in any one of the preceding embodiments, wherein theclocks of a plurality of M2MEs are synchronized.

184. A method as in any one of the preceding embodiments, wherein theM2ME's clock is re-synchronized with a plurality of M2MEs.

185. A method as in any one of the preceding embodiments, wherein theTRE is configured to hold and manage a time base.

186. A method as in any one of the preceding embodiments, wherein theTRE is configured to support synchronization with a trusted time source.

187. A method as in any one of the preceding embodiments, wherein theTRE relies on a trusted time unit located in the M2ME.

188. A method as in any one of the preceding embodiments, wherein theM2ME includes autonomous geo-position equipment.

189. A method as in any one of the preceding embodiments, wherein theTRE has secure access to the geo-positioning equipment.

190. A method as in any one of the preceding embodiments, wherein no twoM2MEs physically establish a radio connection to the same access networkcell at the same time.

191. A method as in any one of the preceding embodiments, wherein theM2ME is provisioned with a destination geo-position (D), and a tolerancerange (R).

192. A method as in any one of the preceding embodiments, wherein thevalues of D and R are stored in the TRE.

193. A method as in any one of the preceding embodiments, wherein thevalues of D and R are cryptographically secured so that only the TRE canaccess the data.

194. A method as in any one of the preceding embodiments, furthercomprising:

the TRE determining its current geo-position;

comparing the current geo-position to D within R; and

releasing the PCID for network access.

195. A method as in any one of the preceding embodiments, wherein theaccess network maintains records of PCID, cell ID pairs.

196. A method as in any one of the preceding embodiments, wherein accessto the network by the M2ME is permitted at a predetermined plurality ofcells.

197. A method as in any one of the preceding embodiments, wherein theM2ME is configured with a plurality of network cell identifiers.

198. A method as in any one of the preceding embodiments, wherein theM2ME is moved geographically.

199. A method as in any one of the preceding embodiments, whereinnetwork access is disabled when the M2ME is moved.

200. A method as in any one of the preceding embodiments, wherein theM2ME is provisioned with a plurality of triples that designate theplaces where a PCID may be used.

201. A method as in any one of the preceding embodiments, wherein atriple includes a PCID, D, and R.

202. A method as in any one of the preceding embodiments, furthercomprising:

determining the current geo-position of the TRE;

comparing the current geo-position to the plurality of triples; and

releasing the PCID associated with the current geo-position.

203. A method as in any one of the preceding embodiments, wherein theM2ME is provisioned with a plurality of quintuples.

204. A method as in any one of the preceding embodiments, wherein aquintuple includes a PCID, D, R, t1, and t2, where t1 designates astarting time, and t2 designates an ending time of the validity period.

205. A method as in any one of the preceding embodiments, whereinquintuples describe a path for M2ME.

206. A method as in any one of the preceding embodiments, whereinfailure of an M2ME to connect to the network at a predetermined timetriggers an alarm.

207. A method as in any one of the preceding embodiments, whereinquintuples may be reprovisioned.

208. A method as in any one of the preceding embodiments, whereinquintuples may be reprovisioned using a PCID update service (PUS).

209. A method as in any one of the preceding embodiments, wherein a PUSis configured to identify the TRE.

210. A method as in any one of the preceding embodiments, wherein theICF includes the PUS.

211. A method as in any one of the preceding embodiments, wherein thePUS is a separate network component.

212. A method as in any one of the preceding embodiments, whereinquintuple reprovisioning includes changes to one or more quintuples.

213. A method as in any one of the preceding embodiments, wherein theTRE's identity is sent to a network server which can associate the TREwith a current network IP address.

214. A method as in any one of the preceding embodiments, wherein remoteprovisioning is delegate to a DPF.

215. A method as in any one of the preceding embodiments, furthercomprising:

the PUS connecting to the M2ME and TRE;

the PUS requesting a validation of the TRE;

the PUS delivering a new plurality of quintuples and a list of oldquintuples to be discarded; and

the TRE installing the new quintuples and discarding the old quintuples.

216. A method as in any one of the preceding embodiments, wherein theTRE is configured to produce pseudo-random numbers which can be adjoinedwith the PCID.

217. A method as in any one of the preceding embodiments, wherein theaccess network is configured to keep track of and distinguish betweenthe pseudo-random numbers.

218. A method as in any one of the preceding embodiments, whereincommunicating entities are the M2ME, the TRE, and a network access point(NAP).

219. A method as in any one of the preceding embodiments, wherein a NAPis an enodeB associated with the VNO.

220. A method as in any one of the preceding embodiments, wherein theTRE is configured to generate a random number (RAND) to be used in asingle initial network connection.

221. A method as in any one of the preceding embodiments, furthercomprising:

the TRE applying an integrity protection method.

222. A method as in any one of the preceding embodiments, wherein theintegrity protection method is a keyed has function where RAND enters asecond parameter, additional data as needed (D1), and a PCID.

223. A method as in any one of the preceding embodiments, furthercomprising:

the TRE sends TRE→eNB: RAND∥PCID∥D1∥M1:=MAC(PCID∥D1, RAND) to the eNB;

the eNB verifies the message authentication code (MAC);

the eNB builds a return package out of the payload data D2, M1; and

the eNB sends the return package to the TRE as eNB→TRE:D2∥M2:=MAC(PCID∥D2, M1.

224. A method as in any one of the preceding embodiments, whereinsubsequent message exchanges include a MAC of a data element thatincludes any new message element and the immediately previous echange'sMAC.

225. A method as in any one of the preceding embodiments, wherein theeNB and the TRE can distinguish message during communication using thelast value M_(n-1) to build the new M_(n).

226. A method as in any one of the preceding embodiments, whereinman-in-the-middle attacks are avoided.

227. A method as in any one of the preceding embodiments, wherein ashared secret is included in messages for authentication of thecommunicating parties.

228. A method as in any one of the preceding embodiments, wherein ashared secret is a negotiated secret.

229. A method as in any one of the preceding embodiments, wherein theMAC values include the PCID.

230. A method as in any one of the preceding embodiments, wherein theeNB maintains a table representing the state of all concurrently activenetwork access attempts (channels) using PCIDs.

231. A method as in any one of the preceding embodiments, wherein thefirst column in the table contains an index of the PICD belonging to thechannel.

232. A method as in any one of the preceding embodiments, wherein theindex points to an entry in a list of all PCIDs currently active for allchannels.

233. A method as in any one of the preceding embodiments, wherein theindex is the PCID value.

234. A method as in any one of the preceding embodiments, furthercomprising:

the eNB receiving a message on a channel TRE→eNB: D3∥M3:=MAC(PCID∥D3,M2).

235. A method as in any one of the preceding embodiments, furthercomprising:

the eNB selecting PCID, from PL for i−1 to N.

236. A method as in any one of the preceding embodiments, furthercomprising:

for all table rows with PCID index I in the first cell, the eNBcalculating M:=MAC(PCID_(i)∥D3, M2), wherein M2 is taken from the secondcell in the row.

237. A method as in any one of the preceding embodiments, furthercomprising:

success state is reached and the search procedure ends.

238. A method as in any one of the preceding embodiments, wherein therow number of the channel corresponding to the last receive thirdmessage is returned.

239. A method as in any one of the preceding embodiments, wherein D3 isadded to the data history and M2 is replaced by M3 in the active hashvalue cell of the selected table row.

240. A method as in any one of the preceding embodiments, wherein amessage contains the index I of the channel to find the associatedchannel fo a subsequent message.

241. A method as in any one of the preceding embodiments, wherein theactive PCIDs are locked.

242. A method as in any one of the preceding embodiments, wherein PCIDsare actively deallocated.

243. A method as in any one of the preceding embodiments, wherein theTRE discards a used PCID when it has been used for obtaining fullnetwork connectivity.

244. A method as in any one of the preceding embodiments, wherein a PCIDis discarded after a validity period has expired.

245. A method as in any one of the preceding embodiments, wherein a PCIDis discarded in response to a request.

246. A method as in any one of the preceding embodiments, wherein adiscarded PCID is used by a different M2ME.

247. A method as in any one of the preceding embodiments, wherein aconnection is established from the TRE to the E/S to signal thedellocation event.

248. A method as in any one of the preceding embodiments, wherein theE/S maintains a list of deallocated PCIDs.

249. A method as in any one of the preceding embodiments, wherein a PCIDis not transferred in clear text during the deallocation process.

250. A method as in any one of the preceding embodiments, whereinvalidation is performed autonomously.

251. A method as in any one of the preceding embodiments, whereinvalidation is performed semi-autonomously.

252. A method as in any one of the preceding embodiments, whereinvalidation is performed remotely.

253. A method as in any one of the preceding embodiments, whereinautonomous validation is performed before the M2ME will allow itself toundergo network attachment.

254. A method as in any one of the preceding embodiments, whereinsemi-autonomous validation includes assessing the validity of the M2MEwithout depending on external network entities.

255. A method as in any one of the preceding embodiments, wherein theresult of a semi-autonomous validation is reported to a remote entity.

256. A method as in any one of the preceding embodiments, wherein theresult includes evidence of the binding of authentication of the TRE tothe M2ME.

257. A method as in any one of the preceding embodiments, wherein theremote entity is the PVA.

258. A method as in any one of the preceding embodiments, wherein thesignaling between the M2ME and the remote entity is protected.

259. A method as in any one of the preceding embodiments, wherein remotevalidation includes an external network entity directly assessing thevalidity and integrity of the M2ME after receiving evidence for thevalidation generated by the TRE and evidence of binging between the TREand the M2ME.

260. A method as in any one of the preceding embodiments, wherein theexternal network entity is the PVA.

261. A method as in any one of the preceding embodiments, wherein thecommunication between the M2ME and the external network entity isprotected.

262. A method as in any one of the preceding embodiments, whereinautonomous validation is performed and no direct evidence of thevalidation is provided to the outside world.

263. A method as in any one of the preceding embodiments, wherein theM2ME fails validation and the TRE prevents it from attaching to anetwork or obtaining an authenticated connection to a remote entity.

264. A method as in any one of the preceding embodiments, furthercomprising:

the TRE checking if it has achieved a predefined state of securestart-up.

265. A method as in any one of the preceding embodiments, furthercomprising:

checking if a predefined portion of the rest of the M2ME that needssecure start-up has achieved a predefined state of secure start-up.

267. A method as in any one of the preceding embodiments, whereinfurther checks are performed by the TRE.

268. A method as in any one of the preceding embodiments, whereinfurther checks are performed by a measuring component in the M2MEexternal to the TRE but integrity-protected by the TRE.

269. A method as in any one of the preceding embodiments, wherein theTRE permits the M2ME to engage in a requested authentication procedure.

270. A method as in any one of the preceding embodiments, whereinautonomous validation is the most economic method in terms of externalcommunication required.

271. A method as in any one of the preceding embodiments, whereinautonomous validation does not permit any outside entity toindependently assess the integrity of the TRE during network access orduring a phase of uninterrupted connectivity.

272. A method as in any one of the preceding embodiments, wherein theTRE stores a log of the validation process and its results.

273. A method as in any one of the preceding embodiments, wherein thelog constitutes an audit record.

274. A method as in any one of the preceding embodiments, wherein theaudit data is stored in a secure internal archive.

275. A method as in any one of the preceding embodiments, wherein thesecure internal archive is within the TRE.

276. A method as in any one of the preceding embodiments, wherein thesecure internal archive is protected by the TRE.

277. A method as in any one of the preceding embodiments, whereintampering with the secure internal archive is detected.

278. A method as in any one of the preceding embodiments, whereinintegrity protection of the data is provided.

279. A method as in any one of the preceding embodiments, wherein auditdata is boutd to the specific purpose for which autonomous validation isinvoked.

280. A method as in any one of the preceding embodiments, wherein thedata includes the purpose of the validation.

281. A method as in any one of the preceding embodiments, wherein sharedsecrets or credentials established in the access protocol are attachedto the audit data and a digital signature is applied by the TRE to theproduced data to protect its integrity.

282. A method as in any one of the preceding embodiments, wherein anentity independent of the M2ME requests the audit data periodically toestablish whether the M2ME is trustworthy at every earlier networkaccess event.

283. A method as in any one of the preceding embodiments, wherein thedata is counter-checked with the network-side protocols about networkaccess attempts to detect tampering.

284. A method as in any one of the preceding embodiments, whereinintegrity of other components, configurations, or parameters of the restof the M2ME is checked when they are loaded, started, or at any other,pre-defined, run-time time event that is available to the measuringcomponent.

285. A method as in any one of the preceding embodiments, wherein theremote entity becomes indirectly aware that the M2ME has passed asemi-autonomous validation test.

286. A method as in any one of the preceding embodiments, wherein thereis explicit signaling to the network of the outcome of a semi-autonomousvalidation.

287. A method as in any one of the preceding embodiments, wherein thesignaling is protected cryptographically.

288. A method as in any one of the preceding embodiments, wherein thesignaling precedes the M2ME authentication required for MID download.

289. A method as in any one of the preceding embodiments, wherein thesignaling includes evidence of the binding between the TRE'sauthentication and the resources in the M2ME used for validity checking.

290. A method as in any one of the preceding embodiments, whereinevidence includes a token sent from the M2ME to the network thatprovides further information for establishing certification of the TREand M2ME.

291. A method as in any one of the preceding embodiments, wherein thePVA or the SHO requests the TRE to perform validation periodically.

292. A method as in any one of the preceding embodiments, wherein thesecurity gateway (SeGW) request validation.

293. A method as in any one of the preceding embodiments, wherein therequest is sent after the M2ME is registered.

294. A method as in any one of the preceding embodiments, wherein therequest is sent once the Home eNodeB (H(e)NB) is authentication for thevery first time by the SeGW.

295. A method as in any one of the preceding embodiments, wherein therequest is sent periodically as a protected operation and maintenance(OAM) message from one or more of the PVA, the SHO, the SeGW.

296. A method as in any one of the preceding embodiments, wherein theperiod of a periodic re-validation is relatively long, but short enoughto make the SHO feel safe about the freshness of the validation.

297. A method as in any one of the preceding embodiments, wherein theTRE performs a validation procedure based on the request.

298. A method as in any one of the preceding embodiments, wherein theTRE generates a time-stamp indicating the last successful validation.

299. A method as in any one of the preceding embodiments, wherein theTRE sends a message indicating that the last validation took placebefore the expiry of the current round of period validation.

300. A method as in any one of the preceding embodiments, wherein thereis no explicit signaling about the outcome of validation.

301. A method as in any one of the preceding embodiments, wherein theM2M1E starts-up to a predefined secure state.

302. A method as in any one of the preceding embodiments, wherein theM2ME requests that the TRE generate evidence of the platform validity.

303. A method as in any one of the preceding embodiments, wherein theTRE collects material to be used to produce evidence of the platformvalidity from the rest of the M2ME.

304. A method as in any one of the preceding embodiments, whereinevidence includes security-critical executable code, credentials for theM2ME's operating system, and equipment ids.

305. A method as in any one of the preceding embodiments, wherein theTRE generates the evidence for the validation of the M2ME andcryptographically protects it for integrity and confidentiality.

306. A method as in any one of the preceding embodiments, wherein theM2ME forwards the protected evidence to the PVA.

307. A method as in any one of the preceding embodiments, wherein thePVA receives the protected evidence and evaluates the evidence todetermine if the M2ME is trustworthy enough to continue to performauthentication and download MIDs.

308. A method as in any one of the preceding embodiments, wherein abinding between the M2ME validation and authentication is performed.

309. A method as in any one of the preceding embodiments, wherein thebinding includes a certificate or credential of the M2ME which atteststo the secure state of the M2ME.

310. A method as in any one of the preceding embodiments, wherein thebinding includes a more secure means of certification.

311. A method as in any one of the preceding embodiments, wherein theM2ME is authenticated by the ICF as a prerequisite for initial networkconnectivity.

312. A method as in any one of the preceding embodiments, wherein a M2MEis authenticated by the DPF to prove it contains an authenticated TREbefore downloading a MID.

313. A method as in any one of the preceding embodiments, wherein theM2ME is authenticated by the SHO before operational network access.

314. A method as in any one of the preceding embodiments, wherein thebinding of validity to network access authentication is implicit forautonomous validation.

315. A method as in any one of the preceding embodiments, wherein tokensare passed in the initial attachment messages which provide furtherinformation on the identity of the TRE.

316. A method as in any one of the preceding embodiments, wherein thereis a logical binding of the TRE holding the authentication credentialsto the M2ME.

317. A method as in any one of the preceding embodiments, wherein theintegrity of the device platform is validated during authentication.

318. A method as in any one of the preceding embodiments, wherein thereis a physical binding of the TRE to the M2ME.

319. A method as in any one of the preceding embodiments, wherein theintegrity of the device platform is validated during TRE authentication.

320. A method as in any one of the preceding embodiments, wherein actualvalidation of the platform resources is performed by using functionalityof a hardware security component securely embedded into the M2ME.

321. A method as in any one of the preceding embodiments, wherein actualvalidation of the platform resources is performed by using hardwaresecurity components that are outside of the TRE but whos securityproperties are assured by the TRE and which have a secure connection tothe TRE.

322. A method as in any one of the preceding embodiments, whereinvalidation and authentication are combined in a session of commonprotocol.

323. A method as in any one of the preceding embodiments, wherein IKEv2is used in a combined validation and authentication procedure.

324. A method as in any one of the preceding embodiments, wherein theICF, DRF, and DPF are individual entities.

325. A method as in any one of the preceding embodiments, wherein theICF, DRF, and DPF are combined.

326. A method as in any one of the preceding embodiments, wherein thedownloading and provisioning of a MID to the M2ME occurs when the M2MEaccesses a 3G VNO's network for initial network access.

327. A method as in any one of the preceding embodiments, wherein theVNO provides an air interface to the M2ME.

328. A method as in any one of the preceding embodiments, wherein theM2ME uses standard GSM/UMTS principles to decode network information andattach to the network of the VNO using an attach message.

329. A method as in any one of the preceding embodiments, wherein anattach message includes a provisional M2ME ID (PCID).

330. A method as in any one of the preceding embodiments, wherein theM2ME is authenticated using standard UMTS AKA procedures by the VNO.

331. A method as in any one of the preceding embodiments, wherein theVNO recognizes the PCID as a IMSI based on its content and structure.

332. A method as in any one of the preceding embodiments, wherein theM2ME and VNO support a common authentication algorithm.

333. A method as in any one of the preceding embodiments, wherein thecommon authentication algorithm is Milenage.

334. A method as in any one of the preceding embodiments, wherein theVNO, recognizing the PCID as and ID for the M2ME, contacts the ICF thatwill accept the PCID as a legitimate preliminary credential.

335. A method as in any one of the preceding embodiments, wherein theICF issues a set of preliminary AVs to protect further communicationwith the M2ME, and starts to provide protected IP connectivity to theM2ME.

336. A method as in any one of the preceding embodiments, wherein theM2ME and the ICF perform a standard AKA process to produce preliminaryAKA keys to protect communication with the M2ME.

337. A method as in any one of the preceding embodiments, wherein theICF redirects the M2ME to the DPF.

338. A method as in any one of the preceding embodiments, wherein theICF sends the PCID to the DRF.

339. A method as in any one of the preceding embodiments, wherein theDRF helps the M2ME find the SHO.

340. A method as in any one of the preceding embodiments, wherein theDRF connects to the SHO and registers the M2ME for connection to theSHO's network.

341. A method as in any one of the preceding embodiments, wherein theSHO requests the PVA to validate the authenticity and integrith of theTRE.

342. A method as in any one of the preceding embodiments, wherein thePVA validates the authenticity and integrity of the TRE.

343. A method as in any one of the preceding embodiments, wherein thePVA sends the validation results to the SHO.

344. A method as in any one of the preceding embodiments, wherein theSHO contacts the DPF and authorizes provisioning of the MID to the M2ME.

345. A method as in any one of the preceding embodiments, wherein theDPF downloads a MID to the M2ME.

346. A method as in any one of the preceding embodiments, wherein theM2ME provisions the downloaded MID into the TRE and reports status ofthe provisioning to the DPF.

347. A method as in any one of the preceding embodiments, wherein theM2ME sends a token for verification of the status message.

348. A method as in any one of the preceding embodiments, wherein thetoken is resistant to tampering and replay attacks.

349. A method as in any one of the preceding embodiments, wherein theDPF reports the status of the provisioning to the SHO.

350. A method as in any one of the preceding embodiments, wherein thedownloading and provisioning of the MID to the M2ME occurs when the M2MEaccesses a 3G VNO's network for initial network access.

351. A method as in any one of the preceding embodiments, wherein theICF requests a PVA to validate the TRE before releasing provisionalauthentication vectors to the M2ME and before allowing an IPconnectivity to the M2ME.

352. A method as in any one of the preceding embodiments, wherein theM2ME owner contacts a new SHO to transfer the M2ME parameters.

353 A method as in any one of the preceding embodiments, wherein theM2ME owner contacts the M2ME to initiate a re-provisioning.

354 A method as in any one of the preceding embodiments, wherein the newSHO requests a validation entity to validate the M2ME.

355 A method as in any one of the preceding embodiments, wherein thevalidation entity validates the M2ME and send results to the new SHO.

356. A method as in any one of the preceding embodiments, wherein thenew SHO requests a DPF to download and provision the new MID to theM2ME.

357. A method as in any one of the preceding embodiments, wherein theDPF securely downloads the new MID package to the M2ME.

358. A method as in any one of the preceding embodiments, wherein theM2ME sends a message to the old SHO that the old MID has be discarded.

359. A method as in any one of the preceding embodiments, wherein theold SHO sends an ACK to the M2ME.

360. A method as in any one of the preceding embodiments, wherein theM2ME forwards the ACK to the DPF and the new SHO.

361. A method as in any one of the preceding embodiments, wherein theM2ME updates it system and installs the MID with the help fo the DPF.

362. A method as in any one of the preceding embodiments, wherein theM2ME sends status to the DPF.

363. A method as in any one of the preceding embodiments, wherein theDPF reports the status to the new SHO.

364. A method as in any one of the preceding embodiments, wherein theM2ME is put in a prestine state and runs an initial provisioningprocedure.

365. A method as in any one of the preceding embodiments, wherein thePVA is responsible for ensuring that any software or firmware (SW/FW)update performed while the M2ME is still subscribed to the same SHo isdone in a secure manner.

366. A method as in any one of the preceding embodiments, wherein thePVA or DPF supervises procedures such as secure on-air or on-wiredownloading of SW/FW and re-provisioning of the M2ME or TRE.

367. A method as in any one of the preceding embodiments, wherein thePVA or DPF employs OMA DM and OMA FOTA procedures.

368. A method as in any one of the preceding embodiments, wherein theM2ME's trust state information is changed due to remote SW/FW update orreconfiguration.

369. A method as in any one of the preceding embodiments, wherein thePVA or DPF is configured to initiate and obtain the results of either anew verifiable boot or run-time trust-state information check of theM2ME or the TRE.

370. A method as in any one of the preceding embodiments, wherein theM2ME is configured to detect tampering.

371. A method as in any one of the preceding embodiments, whereindetecting tampering includes tamerping to any subsystem.

372. A method as in any one of the preceding embodiments, whereintampering detection is performed with frequency.

373. A method as in any one of the preceding embodiments, whereintempering events include one or more of remediable and/or un-remediablecompromise of the OS by malware or viruses, buffer overflow events,sudden unexpected or unauthorized changes in radio or higher-layerconnectivity characteristics and/or environmental readings, excessivelyrepeated failure and/or denial of access or service by trusted networkelements for the M2ME's requests for preliminary authentication,registration, or MID provisioning, or any unexpected/unauthorized changein a post-boot or run-time reading of trust state of the M2ME or M2MEsubsystem relating to remote MID management functionality.

374. A method as in any one of the preceding embodiments, wherein othernetwork elements are configured to detect tampering.

375. A method as in any one of the preceding embodiments, wherein theM2ME takes steps to limit damage in response to tamper detection.

376. A method as in any one of the preceding embodiments, wherein theM2ME is configured to disable remote MID management.

378. A method as in any one of the preceding embodiments, wherein theM2ME is configured to a report of the temper event to a designatednetwork element.

379. A method as in any one of the preceding embodiments, wherein theM2ME is configured to perform remedial actions such as deleting,quarantining, or uninstalling recent software updates or suspectedviruses or malware codes or data.

380. A method as in any one of the preceding embodiments, wherein theM2ME is configured to delete any pre-designated set of data related toremote MID management functions.

381. A method as in any one of the preceding embodiments, wherein theM2ME is configured power down the M2ME or a part or subsystem of theM2ME.

382. A method as in any one of the preceding embodiments, whereinnetwork elements are configured to perform post tamper remedialmeasures.

383. A wireless transmit/receive unit (WTRU) configured to perform atleast part of any one of the preceding embodiments.

384. A machine-to-machine (M2M) equipment configured to perform at leastpart of any one of the preceding embodiments.

385. A network entity configured to perform at least part of any one ofthe preceding embodiments.

1-14. (canceled)
 15. A method for performing validation of a wirelesstransmit/receive unit (WTRU) comprising the following steps performed atthe wireless transmit/receive unit (WTRU): performing at least onevalidation check at the WTRU to produce at least one validation checkresult; reporting the at least one validation check result to a remoteentity, the remote entity and the WTRU being separate entities on anetwork; and after reporting the at least one validation check result,receiving a message from the remote entity accepting or rejectingvalidation of the WTRU.
 16. The method of claim 15, wherein the messageis a validation success message.
 17. The method of claim 16, wherein theWTRU is provisioned after a validation success.
 18. The method of claim16 wherein the WTRU is provisioned with multiple manageable identities(MIDs) after a validation success.
 19. The method of claim 16, whereinthe WTRU is authorized to access a network after a validation success.20. The method of claim 15, wherein the message is a validation failuremessage.
 21. The method of claim 20, wherein the WTRU is prevented fromattaching to a network after a validation failure.
 22. The method ofclaim 15, wherein the at least one validation check includes a securestartup check.
 23. The method of claim 15, wherein the at least onevalidation check includes a check of an integrity of at least onecomponent, configuration, or parameter.
 24. The method of claim 15,wherein the at least one validation check includes an integrity check ofthe WTRU codebase.
 25. The method of claim 15, wherein the at least onevalidation check includes using a trusted environment (TRE) at thewireless transmit/receive unit (WTRU) to do a validation check of theTRE.
 26. The method of claim 25, wherein the at least one validationcheck further includes a secure startup check of other components of theWTRU.
 27. The method of claim 15, wherein the remote entity is aplatform verification authority (PVA).
 28. The method of claim 15,wherein the wireless transmit/receive unit (WTRU) is Machine to Machine(M2M) equipment (M2ME).
 29. A wireless transmit/receive unit (WTRU)comprising a processor and memory, and wherein the further includingcomputer-executable instructions stored in the memory of the node which,when executed by the processor of the node, cause the node to: performat least one validation check at the WTRU to produce at least onevalidation check result; report the at least one validation check resultto a remote entity, the remote entity and the WTRU being separateentities on a network; and after reporting the at least one validationcheck result, receive a message from the remote entity accepting orrejecting validation of the WTRU.